Bir lojistik firmasının sevkiyat takip panelini düşünün. Yazılım ekibi son toplantıda ekranları tek tek gösteriyor: sevkiyat oluşturma, araç atama, teslim fotoğrafı, müşteriye giden bildirim. Her şey akıcı çalışıyor. Toplantıdaki herkes memnun, teslim tutanağı imzalanıyor, son ödeme yapılıyor.
İki hafta sonra operasyon ekibi gerçek işe başlıyor. Aynı gün içinde iki araca bölünen bir sevkiyat sisteme girilemiyor. Müşteri adında "&" olan firmalar bildirimde bozuk görünüyor. Depo sorumlusu, sadece kendi deposunu görmesi gerekirken bütün depoların sevkiyatlarını görüyor. Hiçbiri sunumda yoktu, çünkü sunumda kimse bunları denemedi.
Sunum, yazılımın çalıştığını gösterir. Kabul testi ise yazılımın sizin işinizde çalıştığını göstermelidir. İkisi aynı şey değildir ve aradaki fark çoğu zaman teslimden sonra, düzeltmenin daha pahalı olduğu bir dönemde ortaya çıkar.
1. Kabul ölçütlerini geliştirme başlamadan yazın
"Sevkiyat ekranı olacak" bir ölçüt değildir. "Bir sevkiyat birden fazla araca bölünebilir; her parçanın teslim durumu ayrı izlenir" bir ölçüttür. Kabul testinde neyi deneyeceğiniz, geliştirme başlamadan önce yazılmışsa hem yazılım ekibi neyi yapacağını bilir hem de siz teslimde neye bakacağınızı bilirsiniz.
Bu liste uzun olmak zorunda değil. Her önemli iş akışı için iki üç cümle yeter: kim, neyi, hangi koşulda yapabilmeli ve sonunda ne görmeli. Liste proje boyunca değişebilir; önemli olan değişikliğin de yazıya geçmesi.
2. Gerçek veriyle deneyin
Test ortamındaki "Deneme Firma 1" ve "Ahmet Yılmaz" kayıtları her şeyi kolaylaştırır. Gerçek hayatta ise müşteri adlarında kesme işareti, uzun unvanlar, Türkçe karakterler, aynı vergi numarasıyla iki şube, eksik telefon numaraları vardır.
Teslimden önce kendi verinizden bir örnek hazırlayın: en uzun ve en karışık kayıtlarınızı, en büyük siparişinizi, en çok kalemi olan faturanızı seçin. Bu örnek kişisel veri içeriyorsa maskeleyerek verin. Yazılım bu kayıtlarla da düzgün görünüyor ve doğru hesaplıyorsa, gündelik kayıtlarla sorun çıkarması daha az olasıdır.
3. Ters giden akışları özellikle deneyin
Sunumlar her zaman işin düz gittiği yolu gösterir. Kabul testi ise şu soruları sormalıdır: Kayıt yarıda kalırsa ne olur? İnternet kesildiğinde gönderilen form kaybolur mu? Aynı kayıt iki kişi tarafından aynı anda düzenlenirse hangisi kalır? İptal edilen bir sipariş stoğa geri döner mi? Yanlış girilen bir tutar sonradan düzeltilebiliyor mu, düzeltme kayda geçiyor mu?
Her ana akış için en az bir "ters giden" senaryo yazın ve onu da deneyin. Bu senaryoların çoğu yazılım ekibinin aklına gelir; ama hangisinin sizin işinizde gerçekten yaşandığını yalnızca siz bilirsiniz.
4. Testi, yazılımı her gün kullanacak kişi yapsın
Projeyi yöneten kişi ile yazılımı her gün kullanacak kişi çoğu zaman farklıdır. Yönetici ekranların tamam olduğunu görür; operasyondaki çalışan ise bir işi bitirmek için kaç kez tıkladığını, hangi alanı her seferinde elle doldurduğunu, hangi bilgiyi başka bir ekrandan kopyaladığını fark eder.
Kabul testine en az bir gerçek kullanıcıyı ayırın ve ona bir liste değil, gerçek bir iş günü verin: "Dünkü sevkiyatları sisteme gir." Takıldığı yerleri not almak için yanında biri olsun. Bu yarım gün, teslimden sonra gelecek birçok küçük şikâyeti önceden ortaya çıkarır.
5. Her rolü ayrı bir hesapla deneyin
Yetkiler, kabul testinde en sık atlanan konudur, çünkü test genellikle her şeyi görebilen bir yönetici hesabıyla yapılır. Oysa depo sorumlusu, muhasebe, saha personeli ve müşteri farklı şeyleri görmeli ve farklı şeyleri değiştirebilmelidir.
Her rol için ayrı bir test hesabı isteyin ve her biriyle oturum açıp şunu kontrol edin: Bu kişi görmemesi gereken bir kaydı görebiliyor mu? Adres çubuğundaki numarayı değiştirerek başkasının kaydına ulaşabiliyor mu? Yetkisi olmayan bir işlemi yapabiliyor mu? Bu kontroller hem iş düzeni hem de kişisel verilerin korunması açısından önemlidir.
6. Bulguları tek bir listede ve öncelikle toplayın
Kabul testi sırasında bulgular e-postaya, mesajlaşma uygulamasına ve toplantı notlarına dağılırsa hangisinin düzeltildiği takip edilemez. Tek bir liste tutun ve her bulguya üç bilgi yazın: ne yapıldı, ne bekleniyordu, ne oldu. Bir ekran görüntüsü çoğu zaman bir paragraftan daha açıklayıcıdır.
Her bulguya bir öncelik de verin. "Bu düzelmeden canlıya geçemeyiz" ile "ilk ay içinde düzelsin" ve "sonraki sürüme kalabilir" aynı ağırlıkta değildir. Teslimi neyin engellediği baştan belli olursa tartışma "her şey bitsin" yerine "şu üç madde bitsin" üzerinden yürür.
7. Teslim paketinde yazılımın dışında kalanları da isteyin
Yazılım çalışıyor olabilir, ama onu yarın başka biri devralacaksa çalışması yetmez. Son ödemeden önce şunların elinizde olduğunu kontrol edin: kaynak kodun güncel hâli ve sizin hesabınızdaki depo, sunucu ve servis hesaplarının sizin adınıza olması, kurulum ve yayın adımlarını anlatan kısa bir belge, yönetici hesaplarının şifrelerini değiştirmiş olmanız.
Bu maddeler kabul ölçütlerine yazılmamışsa teslimde unutulması çok kolaydır. Bir entegrasyon projesinde "bitti" kelimesini nasıl tanımlayacağınızı daha önce API entegrasyonu yazımızda anlatmıştık; bütün bir projenin tesliminde aynı tanım bu yedi adımın toplamıdır.
Kabul testine ne kadar zaman ayırmalı?
Küçük bir proje için birkaç gün, büyük bir sistem için bir iki hafta makul bir aralıktır. Önemli olan bu sürenin takvimde baştan yer alması ve düzeltmeler için de zaman bırakılmasıdır. Kabul testini son ödeme gününden bir gün önceye sıkıştırmak, bulunan her eksiği "sonra bakarız"a dönüştürür.
Kısaca
- Kabul ölçütlerini geliştirme başlamadan, her akış için birkaç cümleyle yazın.
- Kendi verinizin en karışık örnekleriyle deneyin.
- Her ana akış için bir ters giden senaryo deneyin.
- Testi, yazılımı her gün kullanacak kişiye gerçek bir iş günüyle yaptırın.
- Her rolü ayrı bir hesapla deneyin.
- Bulguları tek listede, öncelikleriyle toplayın.
- Kaynak kod, hesaplar ve belgeler de teslim paketinin parçası olsun.
Özel yazılım projelerinde kabul ölçütlerini ilk planlama aşamasında müşteriyle birlikte yazıyor, kabul testi için takvimde ayrı bir süre ayırıyoruz.
Böyle bir proje mi planlıyorsun?
10 adımda planla