Kullanıcı kabul testi tek bir soruyu yanıtlar: bu, gerçek senaryolar ve gerçek veriyle, kullanacak kişilerin değerlendirmesiyle işletmenin ihtiyaç duyduğu işi yapıyor mu? İkinci bir kalite güvence turu değildir. Kalite güvence, yazılımın belirtildiği gibi çalışıp çalışmadığını sorar; kabul testi, belirtimin doğru olup olmadığını sorar.
Bu rehber kimlerin test etmesi gerektiğini, net bir karar üreten kabul kriterlerinin nasıl yazılacağını, ne kadar süre ayrılacağını ve projenin son adımda takılmaması için onayın nasıl yürütüleceğini kapsar.
Önemli noktalar
- Kabul testi bir iş faaliyetidir: Geliştirme ekibi değil, işi yapan insanlar yürütür.
- Kriterleri geliştirmeden önce yazın: Sonradan üzerinde anlaşılan kabul kriterleri pazarlığa dönüşür.
- İstisnaları test edin: Olağan akış geçer; sistemin benimsenip benimsenmeyeceğini zor durumlar belirler.
- Takvimin %5–10'unu ayırın: Ve testçilerin zamanını önceden bloke edin, çünkü genelde kayan budur.
Kabul testini kalite güvenceden ayırın
| Kalite güvence | Kabul testi | |
|---|---|---|
| Soru | Belirtildiği gibi çalışıyor mu? | İşi yapıyor mu? |
| Yürüten | Teslimat ekibi | İş kullanıcıları |
| Veri | Test verisi | Gerçekçi, temsilci veri |
| Bulduğu | Kusurlar | Yanlış varsayımlar ve eksik kurallar |
| Çıktı | Hata kayıtları | Kabul, koşullu kabul veya ret |
İkisi de gereklidir. Kalite güvence bitmeden yazılımı kabul testine göndermek, iş kullanıcılarının zamanını ekibin yakalayabileceği kusurlara harcar ve bir dahaki sefere katılma isteklerini kaybetmenin en hızlı yoludur.
İşi yapan testçileri seçin
Doğru testçiler, sistemin günlük işini değiştirdiği kişilerdir, yöneticileri değil ve aylardır geliştirmeye yakın olan proje ekibi değil.
İstisnaları ele alan birini dahil edin. Varsayımları bozan durumları bilirler ve kabul testinin kalite güvencenin bulamayacağını bulmasının nedeni onlardır: kimsenin yazmadığı kural, farklı davranan müşteri tipi, ayın geri kalanına hiç benzemeyen ay sonu süreci.
Zamanlarını resmî olarak bloke edin. Testçilerin günlük işlerine çekilmesi yüzünden kayan kabul testi, gecikmiş yayına geçişin en yaygın nedenidir ve bu bir yazılım değil planlama başarısızlığıdır.
Kabul kriterlerini geliştirmeden önce yazın
Teslimattan sonra yazılan kriterler tartışmaya dönüşür. Önce yazıldığında, iki tarafın da kontrol edebileceği bir sözleşmedir.
İyi kriterler belirli, gözlemlenebilir ve ikili sonuçludur. "Sistem hızlı olmalı" test edilemez. "50.000 kayıt yüklüyken arama iki saniye içinde sonuç döndürür" test edilebilir ve bir tedarikçi buna göre geliştirebilir.
İşlevsel olmayan gereksinimleri de kapsayın: gerçekçi hacimde performans, zayıf bağlantıda davranış, bir entegrasyon erişilemez olduğunda ne olduğu. Bunlar en sık örtük bırakılan ve onay anında en sık tartışılan gereksinimlerdir.
Ekranları değil senaryoları test edin
Ekran ekran gezinti görsel sorunları bulur. Uçtan uca senaryolar önemli olanları bulur.
Senaryoları gerçek bir kişinin tamamladığı eksiksiz yolculuklar olarak yazın: bir siparişi gelişinden karşılanmasına, bir müşteriyi ilk temastan ilk kullanıma, bir ay sonu kapanışını baştan sona. Her birinin bir başlangıç durumu, adımları ve açıkça doğru bir bitiş durumu olmalıdır.
Sonra zor olanları bilinçli ekleyin: iptal edilen sipariş, mükerrer kayıt, standart tipe uymayan müşteri, izindeki onaycı, zaman aşımına uğrayan entegrasyon. Rutin %80'i otomatikleştirmek kolaydır; kalan %20'nin ele alınıp alınmadığı, personelin sistemi benimseyip benimsemeyeceğini belirler.
Gerçekçi veri kullanın
Temiz uydurma veriyle test etmek, sistemin hiç karşılaşmayacağı koşullarda çalıştığını kanıtlar. Temsilci bir gerçek veri kopyası kullanın: dağınık kayıtlar, tarihsel tuhaflıklar, eksik alanlı girişler dahil.
Bu veri kişisel veri içeriyorsa test ortamına ulaşmadan önce anonimleştirin veya takma adlandırın. KVKK ve GDPR kapsamında üretim kişisel verisini güvensiz bir test sistemine kopyalamak yaygın ve önlenebilir bir uyum hatasıdır.
Yeterli süre ayırın ve ikinci tur bekleyin
Proje süresinin %5–10'unu kabul testine ayırın: üç aylık bir projede kabaca bir–iki hafta, birkaç departman dahilse daha uzun.
İki tur planlayın. İlki bulguları ortaya çıkarır; ikincisi düzeltmeleri doğrular. Tek bir kabul testi penceresi ve hemen ardından yayına geçiş planlanan projelerde ikincisi için yer yoktur; bu da ya bilinen kusurlarla yayına çıkmak ya da tarihi alenen kaydırmak demektir.
Bulguları önce sınıflandırın
Kabul testinde dile getirilen her şey kusur değildir. Bulgular üçe ayrılır ve karıştırmak, kabul testi toplantılarının uzamasının nedenidir.
Kusurlar, sistem üzerinde anlaşılmış bir kriteri karşılamıyor. Tedarikçi bunları kapsam içinde düzeltir.
Değişiklik talepleri, sistem anlaşılanı yapıyor ama işletme artık farklı bir şey istiyor. Bunlar fiyatlanır ve planlanır, ücretsiz düzeltilmez.
Yanlış anlamalar, sistem doğru ama testçi başka bir şey bekliyordu. Bunlar eğitim veya belgelendirme konusudur ve arayüz hakkında yararlı sinyaldir.
Kimin sınıflandıracağını ve anlaşmazlıkların nasıl çözüleceğini kabul testi başlamadan kararlaştırın.
Onayın ne anlama geldiğini tanımlayın
Onay, üç olası sonucu olan bir karar olmalıdır: kabul, koşullu kabul veya ret, koşullar ve tarihler adlandırılmış olarak.
Kimin imzalayacağını, hangi ciddiyetteki açık kusurun yayına çıkmayı engellediğini ve koşullu kabul edilen kalemlere yayına geçiş sonrası ne olacağını önceden belirleyin. Sahibi ve tarihi olmayan koşullu kabul, bilinen kusurların kalıcılaşma biçimidir.
Kabul testi bulgularını lansmana taşıyın
Kabul testinin çıktısı yalnızca bir karar değildir. İnsanları neyin şaşırttığının listesidir ki bu eğitim materyaliniz olur; kabul edilen kusurların listesidir ki bu lansman sonrası ilk biriktirme listeniz olur; ve bir sonraki sürüm için gerileme testi olarak saklamaya değer senaryolar kümesidir.
Kabul testini bir kapı sayan ekipler evet ya da hayır alır. Kanıt sayan ekipler bir lansman planı alır.
İlgili rehberler
- Kullanıcı Kabul Testi: Süreç, Kontrol Listesi ve Kriterler rehberinin yanında Özel Yazılım İçin İş Gerekçesi Nasıl Hazırlanır?.
- Kullanıcı Kabul Testi: Süreç, Kontrol Listesi ve Kriterler rehberinin yanında Dijital Dönüşüm İş Ortağı Nasıl Seçilir?.
Kullanıcı Kabul Testi: Süreç, Kontrol Listesi ve Kriterler rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse Yazılım Projenizi Konuşalım.
Ali Boran Gazel