Yazılım kabul testi, iş birimlerinin uygulamanın gerçek iş akışlarını karşılayıp karşılamadığını değerlendirdiği onay aşamasıdır. Bu rehber, senaryo hazırlığından bulgu yönetimine ve canlıya alma kararına kadar uygulanabilir bir UAT çerçevesi sunar.
Yazılım kabul testi nasıl yapılır? Kullanıcı kabul testi ya da UAT, yazılımın teknik olarak çalışmasından öte, işletmenin günlük işlerini doğru biçimde destekleyip desteklemediğini doğrulama sürecidir. Satış, operasyon, muhasebe, müşteri hizmetleri veya yönetim temsilcileri; kendi görevlerini gerçekçi senaryolarla uygular ve ortaya çıkan sonucu beklenen iş kuralıyla karşılaştırır.
UAT’ın sonunda amaç yalnız hata listesi oluşturmak değildir. Kapsamın karşılandığına, açık risklerin bilindiğine ve uygulamanın canlı kullanıma hazır olup olmadığına dair kayıtlı bir karar vermektir. Bu yaklaşım, KepezWeb’un yazılım geliştirme hizmeti kapsamında planlanan özel projelerde iş birimi beklentilerini daha somut hâle getirmek için de kullanılabilir.
Yazılım kabul testi nasıl yapılır: UAT’ın amacı ve sınırı
UAT, geliştirici ekibin birim testi veya kalite ekibinin teknik kontrolleriyle aynı aşama değildir. Teknik testler kodun, entegrasyonların ve sistem davranışının gereksinimlere uygun çalıştığını inceler. Kullanıcı kabul testi ise işin gerçekten yürütülüp yürütülemediğine odaklanır.
| Test türü | Temel soru | Başlıca katılımcı |
|---|---|---|
| Birim testi | Bu fonksiyon doğru çalışıyor mu? | Geliştirici |
| Entegrasyon testi | Sistemler arasında veri doğru akıyor mu? | Geliştirme ve kalite ekipleri |
| UAT | Bu akış, işimizi beklediğimiz şekilde yapmamızı sağlıyor mu? | İş birimi temsilcileri ve süreç sahipleri |
Örneğin bir sipariş ekranının açılması teknik olarak yeterli değildir. Satış temsilcisinin doğru müşteriyi seçebilmesi, gerekli onayların ilerlemesi, stok bilgisinin iş kuralına göre değerlendirilmesi ve ilgili birimlerin doğru kaydı görebilmesi de kabul kapsamına girebilir. UAT, teknik olarak çalışan fakat operasyonel ihtiyacı karşılamayan akışları görünür kılar.
Teste başlamadan önce rol, kapsam ve kabul ölçütlerini belirleyin
Plansız yapılan kabul testinde katılımcılar ekranda rastgele dolaşır; sonuçlar ise kişisel yorumlara dönüşür. Bunun yerine, teste başlamadan önce hangi sürümün deneneceği, hangi iş akışlarının kapsama girdiği ve onay yetkisinin kimde olduğu yazılı hâle getirilmelidir.
- Süreç sahibini atayın: İş kuralını bilen ve kabul kararına katkı sağlayacak sorumlu kişiyi belirleyin.
- UAT katılımcılarını seçin: Sistemi günlük kullanımda farklı rollerle kullanacak temsilcileri dahil edin.
- Sürümü sabitleyin: Hangi ekranların, entegrasyonların ve düzeltmelerin test edildiği net olsun.
- Kapsam dışını yazın: Bu sürümde yer almayan talepleri ve sonraki aşamaya bırakılan işleri ayırın.
- Kabul ölçütlerini tanımlayın: Başarılı sonuç, iş kuralı, zorunlu alan, yetki ve çıktı beklentisini her senaryo için belirtin.
- Karar merciini belirleyin: Canlıya alma, koşullu onay veya erteleme kararının kimler tarafından verileceğini baştan kararlaştırın.
Test verisi de bu hazırlığın parçasıdır. Gerçek müşteri veya çalışan verisi kullanılması gerekiyorsa erişim, gizlilik ve maskeleme kuralları ilgili sorumlularla değerlendirilmelidir. Yeni sisteme taşınan kayıtlar söz konusuysa, Excel’den yazılıma veri aktarımı planı içindeki alan eşleştirme ve örnek veri doğrulama adımları UAT senaryolarına eklenebilir.
Gerçek iş akışlarından UAT senaryosu oluşturun
İyi bir UAT senaryosu, ekran adıyla başlamaz; işletme hedefiyle başlar. Kullanıcının neyi tamamlamak istediği, hangi koşullarda işlem yaptığı ve hangi sonuca ulaşması gerektiği açıkça yazılır. Böylece test, tasarım tercihlerinden çok iş sonucuna göre değerlendirilir.
Her senaryoda bulunması gereken bilgiler
- Senaryonun adı ve iş amacı
- İşlemi yapacak kullanıcı rolü
- Başlangıç koşulları ve kullanılacak test verisi
- İzlenecek adımlar
- Beklenen sonuç ve doğrulanacak iş kuralı
- Kanıt biçimi: ekran görüntüsü, kayıt numarası, rapor çıktısı veya test notu
- Sonuç durumu: başarılı, başarısız, beklemede veya kapsam dışı
Örneğin e-ticaret operasyonunda yalnızca sipariş oluşturmayı denemek yeterli olmayabilir. Siparişin stok rezervasyonuna etkisi, iptal sonrası stok hareketi, farklı kullanıcıların aynı kayda erişimi ve operasyon raporundaki görünümü birlikte test edilmelidir. Bu noktada e-ticaret stok yönetimi rehberi, iş akışındaki kritik stok kontrollerini senaryolaştırmak için yararlı bir referans olabilir.
Olumlu akışların yanında hata ve istisna durumlarını da yazın. Zorunlu alanın boş bırakılması, yetkisiz kullanıcının işlem denemesi, onay reddi, yinelenen kayıt veya bağlantısı kesilen bir dış servis gibi durumlar, gerçek kullanımda karşılaşılabilecek senaryolardır.
UAT yürütümünü kayıt altına alın ve bulguları yönetin
Katılımcıların test sırasında gördüğü her sorun aynı önemde değildir. Bu nedenle bildirimleri tek bir yerde toplamak, tekrarları önlemek ve her bulgunun kararını izlemek gerekir. E-posta, mesajlaşma uygulaması veya sözlü geri bildirim yerine ortak bir test takip tablosu ya da proje kayıt aracı kullanmak daha düzenli bir değerlendirme sağlar.
- Senaryoyu çalıştırın: Tanımlanan adımları mümkün olduğunca sırayla uygulayın.
- Beklenen ve gerçekleşen sonucu karşılaştırın: Sorun varsa hangi adımda ve hangi veriyle oluştuğunu yazın.
- Kanıt ekleyin: Uygun olduğunda ekran görüntüsü, kayıt kimliği veya hata mesajını iliştirin.
- Öncelik verin: İş akışını durduran, alternatif yöntemle sürdürülebilen veya yalnızca iyileştirme niteliğindeki bulguları ayırın.
- Sorumlu ve durum atayın: Bulgunun sahibi, çözüm durumu ve yeniden test gereksinimi görünür olsun.
- Yeniden test edin: Düzeltilen konu için yalnızca hatanın kapandığını değil, ilgili iş akışının etkilenmediğini de kontrol edin.
Kullanıcı deneyimi de kabul değerlendirmesinin bir parçası olabilir. Özellikle müşteri, bayi veya çalışanların kullandığı web tabanlı uygulamalarda klavye kullanımı, form hata mesajları ve okunabilirlik gibi noktalar işin tamamlanmasını etkiler. Bu tür kontroller için web sitesi erişilebilirliği kontrol adımları test listenize uyarlanabilir.
Canlıya alma kararını bulgu değil risk üzerinden verin
UAT sonunda tüm maddelerin aynı anda kapandığı bir tablo her projede oluşmayabilir. Bu nedenle karar, yalnız açık bulgu sayısına göre değil; bulgunun iş etkisine, geçici çözüm bulunup bulunmadığına, veri doğruluğuna ve operasyonun sürdürülme riskine göre alınmalıdır.
| Karar durumu | Değerlendirme ölçütü | İzlenecek yaklaşım |
|---|---|---|
| Canlıya hazır | Kritik iş akışları kabul edilmiş, açık bulgular kararı engellemiyor. | Onay kaydını tamamlayın ve geçiş planını uygulayın. |
| Koşullu kabul | Bilinen açıklar var; etkisi, sahibi ve çözüm yaklaşımı kayıt altında. | Risk kabulünü yetkili kişilerle yazılılaştırın, takip planı oluşturun. |
| Canlıya hazır değil | Temel işlem, veri bütünlüğü, yetki veya operasyon devamlılığı riski bulunuyor. | Önce düzeltme, ardından ilgili senaryoların yeniden testi yapılır. |
Onay belgesinde test edilen sürüm, katılımcılar, kapsam, başarılı senaryolar, açık maddeler, kabul edilen riskler ve karar tarihi yer almalıdır. Böylece canlı kullanım sonrasında ortaya çıkabilecek bir konu için hangi koşullarda onay verildiği geriye dönük olarak anlaşılabilir.
Canlı öncesi UAT kontrol listesi
Canlıya geçişten önce aşağıdaki listeyi proje yapınıza göre gözden geçirin. Her madde için uygun, uygun değil veya takipte gibi net bir durum atamak karar toplantısını kolaylaştırır.
- Test edilen sürüm ve kapsam kayıt altına alındı mı?
- İş birimi temsilcileri kritik senaryoları tamamladı mı?
- Olumlu, hatalı ve istisna akışları denendi mi?
- Kullanıcı rolleri ve yetkileri iş kuralına uygun mu?
- Zorunlu alanlar, hesaplamalar, onaylar ve durum geçişleri doğrulandı mı?
- Taşınan veriler için örnek kayıtlar kontrol edildi mi?
- Entegrasyonlardan gelen veya giden kritik veriler iş birimi tarafından incelendi mi?
- Bildirim, rapor ve belge çıktıları ilgili kullanıcılarca doğrulandı mı?
- Açık bulguların önceliği, sahibi ve yeniden test durumu belli mi?
- Canlı destek, kullanıcı iletişimi ve sorun bildirim kanalı belirlendi mi?
- Gerekli ise geri dönüş veya acil durum yaklaşımı sorumlularla paylaşıldı mı?
- Son kabul kararı yetkili kişiler tarafından kayda geçirildi mi?
Bu liste, her projede aynı ağırlıkta uygulanmaz. Küçük bir iç araç ile çok birimli bir operasyon uygulamasının riskleri farklıdır. Önemli olan, canlıya alma kararını varsayımlara değil, iş biriminin kanıtlanmış senaryo sonuçlarına dayandırmaktır.
Sıkça Sorulan Sorular
UAT testini kim yapmalıdır?
UAT’ı, sistemi günlük işinde kullanacak kişiler veya onların yetkilendirdiği süreç temsilcileri yapmalıdır. Kalite ve geliştirme ekipleri süreci kolaylaştırabilir; ancak iş sonucunun kabulü iş birimi sahiplerinin değerlendirmesini gerektirir.
UAT için teknik bilgi gerekir mi?
Katılımcının yazılım geliştirme bilgisine ihtiyacı yoktur. İş adımlarını, kuralları, istisnaları ve beklenen sonucu bilmesi daha önemlidir. Teknik ayrıntılar, bulgu kaydı sırasında proje ekibi tarafından desteklenebilir.
Her bulunan hata canlıya geçişi durdurur mu?
Hayır. Karar; hatanın iş akışına, veriye, yetkilere ve operasyonun devamlılığına etkisine göre verilir. Ancak temel bir süreci engelleyen veya yanlış işlem yapılmasına yol açan bulgular çözülmeden kabul kararı verilmemelidir.
UAT tamamlandıktan sonra değişiklik yapılabilir mi?
Yapılabilir; fakat değişiklik, kabul edilen sürümü etkileyebilir. Bu nedenle değişen ekran veya iş kuralıyla bağlantılı senaryoların yeniden test edilmesi ve karar kaydının güncellenmesi gerekir.
İş süreçlerinize uygun bir kullanıcı kabul testi planını proje kapsamıyla birlikte değerlendirmek isterseniz KepezWeb ile iletişime geçebilirsiniz. Gereksinimlerinizi paylaşmak ve çözüm kapsamını konuşmak için teklif talebi oluşturabilirsiniz.
