developen

Bir kişiye ne zaman kel dersiniz? Alnı açıldığında mı? Yoksa başının tepesinde bir açıklık oluştuğunda mı? Böylesine muğlak bir durumda nasıl karar veririz? Etrafımızdaki insanları kel yada değil şeklinde sınıflandırmamıza gerek yok, kabul ediyorum. Ama, test mühendisleri olarak yazılımlarda farkettiğimiz anomalileri benzer bir muğlaklık içerisinde sınıflandırıyoruz.

Saptadığınız anomali bug mı? Eğer bir bug ise ciddiyeti nedir? Bu tip soruların yanıtları zordur ve imkan verirseniz kişiden kişiye değişir.

Temellere dönelim ve saçları gür olan bir arkadaşımızı alalım ele. Bu arkadaşımızın saçından bir tel koparırsak bu onu kel yapmaz. Peki saç tellerini teker teker koparmaya devam etsem, hangi aşamadan sonra bu kişi kel kabul edilir?

Günlük yaşantımızda bu tip muğlak durumlarda düşünmeden karar veririz. Eğer bir kişinin kel olup olmadığından emin değilsek, “kelleşiyor” diyebiliriz mesela. Algımızda böylesi iki uç arasındaki ayrım net olmadığında, istemsizce bunu nesnelleştirir ve sınıflandırırız.

Bu duruma felsefede kaygan yokuş yanılsaması (Slippery Slope Fallacy) denir. En basit haliyle aralarında süreklilik barındıran iki terim arasındaki muğlaklıktan kaynaklanır.

Eğer bir anomalinin bug olup olmadığı konusunda karar vermemiz gerekiyor ve aradaki çizgi muğlak ise, bizi zora sokmayacak seçeneği bilinç altımızda gerekçelendirip kararımızı veririz. Bu sebeple gri noktalardaki anomaliler test ekipleri için bug, geliştiriciler için bug değildir. Yönetim ürünün piyasaya çıkış zamanını, destek ekibi ise yanıtlayacakları müşteri taleplerini düşünerek bu kararı verirler. Çoğu zaman verilen kararlar iki kutupta toplanır ve zaten ürün gecikmiştir. “İyimser” görüş kazanır ve kimse mutlu olmaz. Bu sürece yazılımı gerçekten kullanacak ve bu anomaliden etkilenecek kişiler dahil olmamıştır bile.

“Kelleşiyor” kelimesi gündelik hayatta iletişimimiz için yeterli olsa da yazılım üretiminde “bug’ımsı” gibi bir kavramdan memnun olacak pek insan tanımıyorum. Bu konuda ortak anlayış geliştirebilmek için, kaygan yokuş yanılsamasının yaşandığı diğer durumları örnek alabiliriz. Mesela hukuk sistemi, ahlaki kurallardan dolayı embriyo ve yeni doğan arasındaki ayrımı yaparak kürtajı kesin olarak düzenlemiştir. Yada biyoloji bilimi “canlılığı” net biçimde tanımlamıştır ve bu ayrım yüzünden virüsleri canlı kabul etmeyiz.

Eğer benzer bir tanımlama, yazılım hataları için de yapılırsa bu durumda tüm ekip olarak üretilen ürün ile ilgili ortak bir duruş geliştirebilirsiniz. Saptanan her anomali “bug” olur yada olmaz. İlk proje toplantısını izleyen dönemde, Yazılım Test Planınıza ekleyeceğiniz küçük bir tablo söz konusu muğlaklıkları giderecektir.

Show Stopper Hata : Eğer anomali yazılım üzerinde;

1. Run-time hatalara
2. Verilerin geri dönüşsüz kaybına
3. Sistemin yanıt vermemesine
4. Her hangi bir iş akışının devam edememesine
5. Yarattığı etkinin maliyetinin proje sürdürme maliyetlerini geçmesine
6. …..

sebep oluyorsa, “show stopper hatadır” denir.

….

Kritik Hata : Eğer anomali yazılım üzerinde;

1. ….

Anomalinin yaratabileceği etkinin maliyetini de bu sınıflandırma içerisine bir parametre olarak yerleştirmelisiniz. Bu en karmaşık durumlarda bile bu metriği kullanarak objektif bir sınıflandırma yapmanıza imkan verecektir.