Test ve Kabul: Bir Yazılım Ne Zaman 'Bitti' Sayılır?

Test, yazılımın hatasız olduğunu değil, bilinen senaryoların çalıştığını garanti eder. Bu ayrım teslim konuşmalarının yarısını kısaltır: kimse 'hiç hata çıkmayacak' diyemez, ama 'şu yüz senaryonun hepsi denendi ve geçti' denebilir. Kabul kriteri de tam olarak bu ikinci cümledir; birincisi bir temenni, ikincisi bir kayıttır.

Testin ikinci işlevi, tartışmayı nesnelleştirmektir. 'Sistem yavaş' ya da 'bu ekran karışık' cümleleri, test maddesine dönüştüğünde ölçülebilir hâle gelir: hangi ekranda, hangi veriyle, kaç saniyede. Kabul sürecinde en çok zaman kaybettiren şey, herkesin farklı bir şeyi kastettiği belirsiz cümlelerdir.

Bir teslimatın test tarafı, numaralandırılmış ve işaretlenebilir bir katalogla yürümelidir. Her maddenin sabit bir kimliği, bir ön koşulu, bir adım listesi ve beklenen sonucu olur; sonuç ya geçer ya kalır. Sabit kimlik önemlidir çünkü ikinci dalgada 'şu test yine kaldı' demek, ancak testin adı sabitse mümkündür.

Biz kendi ürünlerimizde bu kataloğu yüzlerce maddeye kadar büyüttük ve tek bir sayfada, işaretlenebilir biçimde tutuyoruz. Ekip üyeleri kendi bölümlerini işaretliyor, kalan maddeler bir bakışta görünüyor. Bunun en beklenmedik faydası psikolojik oldu: 'test edilecek' diye tanımsız bir yığın yerine, sayısı belli ve azalan bir liste var.

Katalog aynı zamanda teslim belgesidir. Kabul toplantısında 'neler denendi' sorusunun cevabı, kimsenin hafızası değil o listedir; kalan maddeler de açıkça görünür. Müşteriyle en sağlıklı ilişki, eksiği saklamaktan değil eksiğin listesini birlikte okumaktan doğuyor.

Geliştirici, yazdığı şeyin çalışmasını bekleyerek test eder; kullanıcı ise ne beklediğini bilmeden kullanır. Bu yüzden geliştirici testi doğru yolu doğrular, kullanıcı testi yanlış yolları bulur. İkisi birbirinin yerine geçmez: yalnız geliştirici testiyle teslim edilen bir ürün, ilk gerçek kullanıcıda beklenmedik biçimlerde kırılır.

Kullanıcı testinde en değerli bulgular hata değil, tereddüttür: kullanıcının bir saniye durup 'şimdi ne yapmam gerekiyor' diye düşündüğü an. Bu anlar hata kaydına dönüşmez ama ürünün gerçek kalitesini onlar belirler. Bu yüzden test dalgalarında yalnız 'çalıştı mı' değil, 'takıldığınız yer oldu mu' sorusunu da soruyoruz.

Tek seferlik test yetmez, çünkü bulunan hatalar düzeltildiğinde ortaya yeni bir sürüm çıkar ve o sürüm henüz test edilmemiştir. Doğru kurgu dalgalar hâlindedir: test edilir, bulgular düzeltilir, aynı liste yeniden koşulur. İkinci dalga birincisinden hızlıdır çünkü çoğu madde zaten geçmiştir; üçüncü dalgada genellikle geriye yalnız sınır durumlar kalır.

Dalgalar arasında en sık yapılan hata, test rehberinin her seferinde yeni bir dosya olarak paylaşılmasıdır. İkinci dalgada kimse hangi dosyanın güncel olduğunu bilmez. Biz bunun yerine tek bir adres kullanıyoruz: rehber hep aynı bağlantıda yaşar, her dalgada güncellenir. Katılımcı için tek bir yer vardır ve o yer her zaman doğrudur.

Otomatik testler, insanın tekrar tekrar kontrol etmesi saçma olan şeyler için vardır: iş kuralları, hesaplamalar, yetki sınırları, veri dönüşümleri. Bu tür testler bir kez yazılır ve her değişiklikte bedava koşar; asıl değerleri de buradadır — bugünü değil, altı ay sonra birinin farkında olmadan bozacağı şeyi korurlar.

Yeterli olmadıkları yer ise arayüzdür. Bir ekranın 'kullanılabilir' olup olmadığını otomatik test söylemez; hizalamayı, okunabilirliği, dar ekranda bozulan bir başlığı ancak insan görür. Bizim dengemiz şu: iş mantığı ve yetki tarafında sunucu tarafı otomatik testler, arayüz tarafında numaralı insan testi. Her ikisine de aynı anda yatırım yapmak çoğu projede gereksiz pahalıdır.

Test listesine 'yetkisiz hesapla erişmemesi gereken bir şeyi dene' maddesini koymanın sebebi bir vakadır. Yayın sonrası kısa kontrol sırasında, sıradan bir kullanıcı hesabıyla yapılan bir çağrının ait olmadığı bir kurumun verisini döndürebildiğini fark ettik. Ekranlar açılıyor, kod hata vermiyor, testlerin hepsi geçiyordu — çünkü hiçbir test 'yapmaması gerekeni' denemiyordu.

Buradan çıkan kural genel: testlerin bir kısmı olumsuz senaryo olmalı. Yalnız 'doğru kullanıcı doğru şeyi görüyor mu' değil, 'yanlış kullanıcı yanlış şeyi göremiyor mu' da sorulmalı. Çok kiracılı sistemlerde bu, isteğe bağlı bir kontrol değil zorunlu bir maddedir; bir kiracının verisinin başka bir kiracıya görünmesi, düzeltilebilir bir hata değil, güven kaybıdır.

İyi bir hata bildirimi üç şeyi içerir: ne yaptım, ne bekliyordum, ne oldu. Bu üçü yazıldığında geliştiricinin sorması gereken soru kalmaz; yazılmadığında ise hata kaydı bir yazışmaya dönüşür ve düzeltme günlere yayılır. Test dalgalarında en çok kazandıran şey, katılımcılara bu üç satırlık kalıbı baştan vermektir.

Bunun yanına iki ek koymak faydalı: ekran görüntüsü ve kaydın kimliği. Görüntü, 'karışık görünüyor' cümlesinin ne demek olduğunu tek bakışta anlatır; kayıt kimliği ise hatanın hangi veriyle oluştuğunu gösterir. Aynı ekran bir kayıtta düzgün, diğerinde bozuk çalışıyorsa fark verinin kendisindedir ve o farkı ancak kimlikle bulursunuz.

Bir de tekrarlanabilirlik notu: hata her seferinde mi oluyor, yoksa bir kez mi görüldü? 'Bir kez oldu, sonra tekrarlayamadım' bilgisi bile değerlidir, çünkü geliştiriciye bunun bir zamanlama ya da veri durumu sorunu olabileceğini söyler. Tekrarlanamayan hataları kayıt dışı bırakmak, en zor hataları görünmez kılar.

Bulguları önceliklendirmenin en sağlam ölçüsü, 'bu hâliyle yayına çıkabilir miyiz' sorusudur. Veri kaybına, yanlış hesaplamaya ya da yetkisiz erişime yol açan hiçbir bulgu yayına çıkamaz — bunlar tartışmasız engelleyicidir. İşi yavaşlatan ama alternatif yolu olan bulgular çıkabilir; görünüm ve rahatlık bulguları ise sonraki sürüme kalabilir.

Bu üç kademe basit görünür ama tartışmayı bitiren şey basitliğidir. Beş kademeli önem ölçekleri, pratikte herkesin kendi işini 'yüksek' işaretlemesiyle sonuçlanır. Kademeyi kim verirse versin, kararın sahibi işi bilen kişi olmalı — geliştirici düzeltmenin zorluğunu bilir, önemini değil.

Düzeltilen bir hatanın geri gelmesine regresyon denir ve sebebi genellikle şudur: hata düzeltildi ama o hatayı yakalayan bir test yazılmadı. Aylar sonra başka bir değişiklik aynı kodu etkiler ve kimse fark etmez. Bu yüzden kuralımız şu: bir hata iki kez görüldüyse, düzeltmesiyle birlikte otomatik bir testi de yazılır.

İkinci sebep, düzeltmenin belirtiye yapılmasıdır. Görünen sonucu yamalayıp kökene inmemek, hatayı başka bir yerden geri getirir. Bunu ayırt etmenin pratik yolu şudur: düzeltmeyi yapan kişi 'bu neden oluyordu' sorusunu bir cümleyle cevaplayabiliyor mu? Cevaplayamıyorsa muhtemelen belirti kapatılmıştır.

İyi bir kabul kriteri, tartışmaya yer bırakmayacak kadar somuttur ve iş diliyle yazılır. 'Rapor ekranı hızlı olacak' değil, 'bir aylık veriyle rapor beş saniyede açılacak'. 'Kullanıcı yönetimi olacak' değil, 'yönetici kullanıcı ekleyebilecek, rolünü değiştirebilecek ve pasife alabilecek'. Kriteri yazan kişi geliştirici değil, işi bilen kişi olmalıdır.

İkinci kural, kabulün bir tarihe değil bir listeye bağlanmasıdır. Tarihe bağlanan kabul, o gün ne durumda olunursa olunsun imzalanır ve eksikler 'sonra hallederiz'e kalır; listeye bağlanan kabul ise neyin bittiğini ve neyin kalmakta olduğunu net gösterir. Biz teslimlerde bu iki listeyi yan yana koyuyoruz: geçenler ve kalanlar.

Bir teslimatta en çok güven kazandıran şey, olmayanı açıkça söylemektir. Kendi ürün sayfalarımızda henüz yapılmamış özellikleri 'yakında' diye işaretliyoruz; satış konuşmasında kısa vadede maliyeti var ama uzun vadede tersini yapmanın bedeli çok daha yüksek. Var sanılan bir özelliğin yokluğu, teslimden sonra ortaya çıktığında bütün projeyi tartışmalı hâle getirir.

Bunun pratik hâli, kapsamın üç kutuya ayrılmasıdır: bu teslimde var, bu teslimde yok ama yol haritasında, hiç yapılmayacak. Üçüncü kutu genellikle atlanır ve en çok yanlış anlamayı o yaratır. Bir şeyin bilinçli olarak yapılmadığını söylemek, unutulduğunu düşündürmekten iyidir.

Test verisi gerçeğe ne kadar benzerse, test o kadar işe yarar. Elle girilmiş üç örnek kayıtla yapılan test, listelerin uzunluğunu, arama sonuçlarının kalabalığını, uzun isimlerin ekranı nasıl bozduğunu ve sayfalamanın çalışıp çalışmadığını hiç göstermez. Bu yüzden test ortamına gerçek verinin bir kopyası alınır — sistemin kalabalıkta nasıl davrandığı ancak böyle görülür.

Ama gerçek veri kopyalanırken kişisel bilgilerin maskelenmesi gerekir: isim, telefon, e-posta ve kimlik bilgileri test ortamında gerçeğiyle durmamalıdır. Test ortamları çoğu zaman canlı kadar korunmaz; oradan sızan bir veri, canlıdan sızan kadar sorumluluk doğurur. Maskeleme betiği, veri kopyalama betiğinin ayrılmaz parçası olmalıdır.

Bir de sınır verisi vardır: en uzun isim, en büyük dosya, en kalabalık liste, geçmiş tarihli kayıt, silinmiş kullanıcıya ait kayıt. Bunlar gerçek veride nadiren bulunur ama gerçek hayatta mutlaka ortaya çıkar. Test kataloğuna birkaç sınır maddesi eklemek, yayından sonra 'kimse bunu denemez sanmıştık' cümlesini duymanın önüne geçer.

Teslim, yazılımın çalışmasıyla değil, müşterinin onu yönetebilmesiyle biter. Bunun testi basittir: içeriği kim güncelleyecekse, o kişi hiç yardım almadan bir metni değiştirebiliyor mu, bir kullanıcı ekleyebiliyor mu, bir kaydı yayından kaldırabiliyor mu? Cevap hayırsa, ürün bitmiştir ama teslim bitmemiştir.

Devrin ikinci ayağı, sistemin nasıl çalıştığının yazılı olmasıdır: hangi ortam nerede, sürüm nasıl çıkılır, yedek nereden alınır, bir şey bozulursa kim ne yapar. Bu belge uzun olmak zorunda değil; bir sayfa doğru bilgi, otuz sayfa genel geçer metinden değerlidir. Biz bu notları projenin kendi hafıza dosyalarında tutuyoruz, çünkü bir yıl sonra soran kişi çoğu zaman yine biz oluyoruz.

Bir yazılım, listesi biterek bitmez; listesi görünür olduğunda biter. Numaralı bir test kataloğu, dalgalar hâlinde tekrarlanan bir kontrol, olumsuz senaryoları da içeren bir güvenlik maddesi, iş diliyle yazılmış kabul kriterleri ve dürüstçe işaretlenmiş bir eksikler listesi — teslimi tartışmadan çıkarıp kayda dönüştüren şey bunlar.

Bu üç yazılık seri teslim sürecinin üç adımını anlatıyor: canlıya alma, veri göçü ve test/kabul. Elinizde teslim edilmeyi bekleyen bir proje varsa ya da mevcut süreciniz her seferinde aynı yerde tıkanıyorsa, hangi adımda olduğunuzu konuşarak başlayabiliriz.