developen

Birkaç ay önce QualiTest bünyesindeki görevime Hollanda şubesinde devam etmem konusunda aldığımız kararı uygulamaya başladık ve 5 haftadır Türkiye’den uzak yaşamaktayım. Bu süre zarfında hayatımdaki değişikliklere adapte olmak tüm enerjimi tüketmekte ve yazacak entellektüel gücü kendimde bulmakta zorlanıyorum.

Lakin ne olursa olsun, Michael Bolton‘ın 13 Ocak tarihli blog yazısında anlattığı tartışmayı buraya taşımamak gerçekten ayıp olacaktı. Bu tartışma, yazılım hatalarının saptanması konusunda Epistemoloji’nin kullanımına mükemmel bir örnekti.

Tartışma şu şekilde; 11 Eylül olaylarında Dünya Ticaret Merkezi’nin iki kulesine, iki ayrı uçak çarptı(rıldı). Bu iki ayrı uçağın çarpması tek bir olay mıdır, yoksa iki ayrı olay mı? Kimileri bunu tek bir olay olarak görebilir, zira tüm eylem tek bir eylem planının eseriydi ve tek bir grup tarafından organize edildiler. Diğer taraftan, iki ayrı olay olarak kabul edenler de haklı olabilir çünkü iki farklı bina, iki farklı grup tarafından kaçırılan iki alakasız uçak söz konusu.

"Kimin umurunda?" diyebilirsiniz, "her koşulda binden fazla insan hayatını kaybetti, bunları düşünmek o insanları geri getirmez!" de denebilir. Böyle bir tartışmanın ne kadar değeri olabilir ki?

Sanırım yukarıdaki sorunun yanıtının değeri 3.5 milyar amerikan doları. WTC’yi kiralayan  Lerry Silverstein, her bir yıkıcı olay başına 3.5 milyar USD limitli bir sigorta poliçesine sahipmiş. Yukarıdaki soru ile ilgili çeşitli mahkemeler ve juriler farklı sonuçlara varmışlar. Yukarıdaki formüle göre de, Michael Bolton’ın da dediği gibi, "üç aşağı beş yukarı çarpan uçaklardan birinin yarısı(?) ayrı bir olay olarak değerlendirilmiş" ve 5 milyar dolar ödenmiş.

Yazılım geliştirenler olarak biz yaptığımız işin detaylarına o kadar dalarız ki, yazılımların gerçek amacını unutuveririz. Biz hangi veri tabanını kullanmanın daha uygun olacağını, hangi veri yapılarının arama sonuçlarını sıralamak için daha verimli olduğunu düşünürüz. Ama gerçek dünyada bunların bir anlamı yoktur. İnsanlar yazılımları belirli bir işi daha verimli yapabilmek için satın alırlar. Bizim çalıştığımız birimlerin girdileri ve çıktıları haricinde hiçbirşey, yapılan "o işi" ve müşterileri ilgilendirmez.

Bu sebeple Test Mühendisleri, test altındaki yazılımın amaçlarını çok iyi kavramalı ve yazılım yaşam döngüsü boyunca bu amaçların karşılanıp karşılanmadığını akıllarından çıkarmamalıdırlar. Çoğu zaman kendinize soracağımız sorular yukarıdaki tartışmadan daha basit değildir. Sorun şu ki, bir yanıt gereklidir ve bu yanıt "yazılımın yapması beklenen iş dikkate alındığında" şartların imkan verdiği en optimum yanıt olmalıdır.

Ne zaman böyle karmaşık durumlarda dahil, yargılarımıza refleks olarak varabiliriz, işte o zaman iyi bir Test Mühendisi olmaya adayız demektir. Sadece bu yüzden bile diyebiliriz ki, epistemoloji test mühendisliği için olmazsa olmaz bir araçtır.

İyi Testler!

Not : Yazamadığım süre içerisinde e-posta’ları ile beni yalnız bırakmayan arkadaşlarıma buradan teşekkür ederim. Bir dönem yazılım düzensiz zamanlarda yayınlanacak lakin yaklaşık 3-4 hafta sonra, eski düzenimde yazmaya başlamayı planlıyorum.