Yazılım Kabul Testi ve Teslim Kriterleri Nasıl Kurulur

Bir yazılımı teslim alırken sınanması gereken şey ekranların açılıp açılmadığı değil, işletmenin günlük işinin o yazılım üzerinden baştan sona yürüyüp yürümediğidir. Bunun yöntemi kabul testidir: işi fiilen yapan kullanıcıların, önceden yazılmış kriterlere göre gerçek iş akışlarını deneyip sonucu kayda geçirmesi.

Kabul testi son haftaya sıkıştırılan bir formalite değil, en başta kararlaştırılan bir ölçüm düzenidir. Aşağıda kriterlerin yazılmasından kabul tutanağına kadar süreci ele alıyoruz.

Kabul kriteri proje başında yazılır

Teslim tartışmalarının büyük bölümü tek bir kelimeden çıkar: "çalışıyor". Geliştiren taraf için çalışmak, ekranın hata vermeden kaydetmesi olabilir; işletme için doğru fiyatın, doğru iskontoyla ve doğru stok hareketiyle oluşması anlamına gelir. Bu iki tanım eşitlenmediği sürece kabul süreci pazarlığa dönüşür.

Bu yüzden kriterler, geliştirme başlamadan önce ölçülebilir cümlelerle yazılır. "Sipariş ekranı çalışacak" bir kriter değildir; "bayi grubuna tanımlı iskonto satıra otomatik gelir, kullanıcı bu oranı yetkisi kadar değiştirebilir, değişiklik kayıt altına alınır" bir kriterdir. Ölçülebilirliğin işareti şudur: iki ayrı kişi aynı kriteri okuyup aynı sonuca varıyorsa kriter yazılmıştır. Her madde için üç soru cevaplanır: hangi rolle, hangi veriyle denenecek ve hangi sonuç doğru kabul edilecek? Beklenen sonucu önceden yazmayan ekip, testte çıkan sonucu beklenen sonuç sanma eğilimindedir.

Testi kim yapar: BT değil, işi yapan kullanıcı

En sık yapılan hata, testi BT sorumlusuna ya da projeyi yürüten kişiye bırakmaktır. O kişi sistemi kendi kurduğu için doğru yolu bilir ve gerçek kullanıcının yaptığı sapmaları hiç denemez. Oysa yazılım gün içinde telefonla konuşurken, müşteri karşısında ve acele ederek kullanılacaktır.

Doğru kurgu şudur: her modülü, o işi fiilen yapan kişi test eder. Siparişi satış görevlisi, depo hareketini depo sorumlusu, cari ekranını muhasebeyle çalışan kişi dener. BT sorumlusunun rolü test etmek değil; testi düzenlemek, bulguları toplamak ve tekrar üretimi doğrulamaktır.

• Her modül için bir ad belirlenir; kabul o kişinin onayıyla kapanır.
• Takvimde gerçek saat ayrılır; kullanıcıdan "arada bakarım" beklenmez.
• Kullanıcıya nereye tıklayacağı söylenmez; bulamaması da bir bulgudur.

Senaryolar gerçek işe benzemeli

Ekran ekran gezerek yapılan test, modüllerin birbirine bağlandığı yerleri görmez; hatalar çoğunlukla tam orada, bir belgeden diğerine geçişte çıkar. Bu nedenle senaryolar ekran değil iş akışı üzerine kurulur ve baştan sona götürülür.

1. Bir teklif oluşturulur, revize edilir, siparişe çevrilir ve sevk edilir.
2. Sevk edilen bir kalem iade alınır; stok, cari bakiye ve belge izi kontrol edilir.
3. Aynı müşteriye farklı fiyat listesinden ikinci bir sipariş girilir, fiyatın hangi listeden geldiği doğrulanır.
4. Bir ay sonu kapanışı denenir; dönem raporları belge toplamlarıyla karşılaştırılır.
5. Aynı senaryo küçük ekranda yeniden yürütülür, çünkü sahadaki kullanım biçimi budur.

Senaryo bittiğinde sorulacak soru "hata verdi mi" değil, "çıkan sayılar elde tuttuğumuz kayıtla aynı mı" olmalıdır; sessizce yanlış sonuç üreten akış, hata mesajı veren akıştan daha tehlikelidir.

Test verisi gerçeğe benzer, ama gerçek olmaz

Test ortamı dolu olmalıdır; boş bir sistemde yapılan test hiçbir şey göstermez. Fakat "canlı veritabanının kopyasını atalım" yaklaşımı ciddi risk taşır. Test ortamları canlı kadar korunmaz: erişimi daha geniştir, yedek düzeni farklıdır, geliştirici bilgisayarlarına indirilebilir. Müşteri adı, telefonu, adresi ve ödeme bilgisi buraya kopyalandığında kişisel veri korumasız bir alana taşınmış olur.

Doğru yaklaşım, gerçeğe benzeyen fakat gerçek olmayan veri üretmektir: kişisel alanlar maskelenir ya da üretilir, veri yapısı gerçeğe benzer tutulur. Uzun firma adları, Türkçe karakterli unvanlar, çok satırlı adresler, aynı isimli iki cari, iskontolu ve iskontosuz gruplar, geçmişe dönük hareketler test ortamında bulunmalıdır. Tek satırlı "Test Müşteri 1" verisiyle yapılan test, canlıda karşılaşılacak hiçbir sorunu göstermez.

Sınır durumları özellikle denenir

Normal akış genellikle ilk günden çalışır; projeyi zora sokan durumlar kimsenin denemeyi düşünmediği uç noktalarda çıkar. Bunlar ayrı bir başlık olarak listelenir.

• Negatif ve sıfır stok: Elde olmayan malın satılması engelleniyor mu, engellenmiyorsa kim izin veriyor?
• İskonto üst sınırı: Yetkisinin üstünde iskonto girildiğinde onaya mı düşüyor, sessizce mi geçiyor?
• Eksik veri: Adresi ya da vergi bilgisi olmayan kayıt belge üretebiliyor mu?
• Aynı kayda iki kullanıcı: İki kişi aynı siparişi aynı anda kaydederse son kaydeden diğerinin değişikliğini siliyor mu?
• Çok büyük belge: Yüzlerce satırlı sipariş ya da uzun tarih aralıklı rapor kabul edilebilir sürede dönüyor mu?
• Tekrar gönderim: Kaydet düğmesine iki kez basılırsa iki belge mi oluşuyor?

Hata kaydı nasıl açılır

"Çalışmıyor" yazan bir bildirim geliştirici tarafında hiçbir şey başlatmaz. Kullanılabilir bir hata kaydı en az şunları içerir: hangi kullanıcı rolüyle girildiği, adım adım tekrar üretim yolu, kullanılan veri, beklenen sonuç, gerçekleşen sonuç, tarih-saat ve ekran görüntüsü. Ekranda görünen hata metni varsa birebir yazılır.

Tekrar üretim adımları kaydın en değerli kısmıdır; tekrar üretilemeyen hata "bende olmuyor" cevabıyla dolaşır ve kapanmaz. Kullanıcıya şu alışkanlık kazandırılmalıdır: hatayı görür görmez aynı adımları yeniden yürümek ve hangi adımda tekrarlandığını not etmek.

Önem derecesi ve hangi seviye teslimi durdurur

Bütün hatalar aynı değildir; hepsinin kapanmasını beklemek teslimi süresiz erteler. Bu yüzden bulgular derecelendirilir ve hangi derecenin teslimi engellediği baştan yazılır.

Veri bütünlüğünü bozan ve para hesabını etkileyen her bulgu, görünürde küçük olsa da durdurucu sayılır. Yanlış yuvarlanan bir tutar kozmetik değildir.

Yetki testi ayrı yapılır

Kabul testi genellikle tek bir yönetici hesabıyla yapılır ve her şey çalışır görünür, çünkü yönetici her şeyi görür. Oysa gerçek kullanım kısıtlı rollerle olur; bu yüzden yetki testi ayrı bir oturum olarak planlanır ve her rol için gerçekten o rolle giriş yapılır. İki yön birlikte sınanır: rol yapması gereken işi yapabiliyor mu, bir de yapmaması gereken şeye erişemiyor mu? İkincisi sıkça atlanır; menüden kaldırılmış bir ekranın adresi doğrudan yazıldığında açılıyorsa yetki kurulmuş sayılmaz.

Kabul tutanağı ne içerir

Kabul, sözlü bir "tamam" değildir. Yazılı tutanak hem işletmeyi hem geliştireni korur, çünkü neyin teslim edildiğini ve neyin açık kaldığını sabitler. İçeriği şudur: kabul edilen kapsam, test edilen senaryolar ve sonuçları, kapanan bulgu sayısı, açık bulgular ile önem dereceleri ve kapanma takvimi, devredilen ortam bilgileri, eğitim ve doküman teslim durumu, imza atanlar ve tarih. Açık bulguların yazılması kabulün zayıflığı değil sağlığıdır; yazılmayan bulgu haftalar sonra "bu zaten baştan böyleydi" tartışmasına dönüşür.

Kısa kontrol listesi

• Kabul kriterleri geliştirme başlamadan, ölçülebilir cümlelerle yazıldı mı?
• Her modülün testini o işi fiilen yapan kullanıcı mı yürütüyor?
• Senaryolar baştan sona iş akışı olarak mı kurulu?
• Test verisi gerçeğe benziyor ama gerçek müşteri verisi değil, değil mi?
• Sınır durumları ayrı bir liste olarak denendi mi?
• Bulgular tekrar üretim adımlarıyla, beklenen ve gerçekleşen sonuçla mı açılıyor?
• Önem dereceleri ve teslimi engelleyen seviye yazılı mı?
• Her rol için ayrı oturumla yetki testi yapıldı mı?
• Tutanakta açık bulgular ve kapanma takvimi var mı?

KAV Yazılım, işletmelere özel yazılım geliştirirken kabul kriterlerini ve test senaryolarını projenin başında birlikte yazar; teslim bu kriterlerin ölçülmesiyle kapanır.