developen

“Yazılım testi” dendiğinde herkesin aklına birşeyler gelebilir. Kimileri yeni mezun arkadaşlara yaptırdıkları ve böylece yükümlülüğünden kurtuldukları bir aktivite, kimileri ise yazılım üretiminin artık sonu geldiğini hatırlatan bir “iş” olduğunu düşünebilir. Ben ise bunun dışında şeyler düşünüyorum.

“İyi yazılım testi” kavramını tanımlamadan önce, yazılım testinin bazı amaçlarını sıralamamız gerekiyor.

Kabul etsek de etmesek de test ekiplerinin temel motivasyonu, hata bulmaktır. Evet “hata bulmadan da iyi test yapılabilir, uygulamanın iyi olduğundan emin oluruz” diyenler olduğunu duyuyorum. Gerçek hayatta ne yazık ki kazın ayağı öyle değil. Yazılımda hata bulunamaması, sadece yazılım üretim süreçlerine mahsus olmayan sebeplerle, bazı diğer şeyleri tetikleyecektir. Örneğin testlerin durdurulması gibi. Nedense şöyle birşey söylemek geldi içimden : “Zaten bu yüzden test mühendisleri iyi test yapmak zorunda değil mi?”.

O halde Test Mühendisi nerede hata bulabileceğini bilmelidir! Evet, otomativ sanayiinde, üretim hatalarını ppm (pieces per million) ile ölçüyor olabilirler. Kabul aşamasında ve ekipçe cleanroom ile çalışmış olsak bile, bin test vakası başına bir onda küsur hata gibi bir oranla çalışıyorsak, ”hata bulamamak soru işaretleri oluşturur” demek garip gelmemeli. Bunu tabii ki test mühendisi, bilgi ve deneyim yoluyla ve zaman içerisinde geliştirerek öğrenir. Lütfen diğer yolları unutun!

Testin diğer amacı, yazılım hataları ve yazılımın çalışma ekosistemine dair riskleri yönetilebilir kılmaktır. Her zaman mükemmel bir test planını, mükemmel bir biçimde uygulayamayabilirsiniz. Bunun zaman, test ortamı ile ilgili eksiklikler yada test ekibi dışındaki organizasyondan kaynaklanan diğer sorunlar gibi sebepleri olabilir. Bu gibi durumlarda dahi, yazılım testi, mümkün olan, hacmen en yüksek miktardaki riski çevrelemelidir. Evet, bazen uygulamanın her ince detayını test edemeyebiliriz ama en fazla riski barındıran yerleri mutlaka..

Testin belki de en önemli amaçlarından birisi de yazılım ile ilgili diğer ekip arkadaşlarına bilgi sağlamaktır. Bu bilgiler yazılımın yayıma ne kadar hazır olduğu, yazılımın kalite seviyesi, yazılım üzerinde belirli bir işin, en kolay ve sorunsuz biçimde, nasıl gerçekleştirilebileceği gibi bilgilerdir. Belki de içinde çalıştığım her ciddi projenin sonlarında, teknik yazarların benim ile toplantı yapmasının sebebi bu olabilir mi? Efendim?

Testin en belirgin amacı, yazılımın uygunluğu ile ilgili karar vermektir. Yazılımı yayıma uygunluğu, standartlara uygunluğu, kabul şartnamesine uygunluğu gibi konular test aktiviteleri ile belirlenir. Her projemde ben, özellikle bu üç konu ile ilgili yayım vetosu hakkı talep ederim.

Testin diğer bir konusu ise ekipteki diğer arkadaşların işlerine yardımcı olmaktır. Örneğin yazılımın kendi içindeki bağımlılıklarını yazılım mimarı ile test ekip liderleri bilir. Eğer ekibinizde yazılım mimarınız yoksa, mutlaka bir test mühendisiniz olsun. Ayrıca teknik destek ekibine hem iş güçlerini düşürerek (en büyük bahanemiz “ama bu düzeltilmezse şu kadar destek telefonu alırız”dır), hem de çıkan genel sorunların ne şekilde çözülebileceği konusunda aktif destek vererek yardımcı oluruz. Üzülerek (aslında gülümseyerek) söylemeliyim ki, “vakti olmayan” ekip arkadaşları bizlerin dokümantasyonlarını, “fikri olmayan” tasarımcılar bizim fikirlerimizi kullanır.

Testin belki de en güzel amacı, yazılım geliştirme sürecine katkı sağlamak ve yazılım kalite güvencesi aktiviteleri uygulamaktır. Eğer sürekli olarak validasyon hataları bulunuyorsa, sizi temin ederim, bu konuyla ilgili sızlanan ve üretim ortamında bu hataların oluşmasını engelleyecek çalışmaları zorlayan test ekipleridir. Eh bir de kalite güvencesi aktiviteleri vardır ki, bu nokta biraz karışık. Yazılımı tüm yazılım geliştirme ekibi kaliteli hale getirir. Sadece “test ederek” bir yazılımı daha kaliteli yapamazsınız. Test, yazılımın kalite seviyesini denetleyen bir aktivitedir. Ben hiçbir zaman -tamam bazı zamanlar hariç- bulduğum bir yazılım hatasını düzeltmem. Görevim tebliğ etmektir. İşte bu noktada test ekibi, tüm ekip içerisinde ilginç bir görev de üstlenir. Sürekli olarak yazılım kalitesi ile ilgili konuları gündeme getirerek, tüm ekip içerisinde konu ile ilgili farkındalık yaratır. Testin amacı bu yüzden biraz da “sızlanan bir kitle” yaratmaktır.

O halde bu bilgiler ışığında, bence iyi bir test aşağıdaki kriterler ile yapılır..

1. Gerektiğinde, teste erken başlamak için, ekibin kalanının geliştirmesi gereken dağarcığı, üstlenip, üretip paylaşarak
2. Her aşamada test sonuçlarını, herkese açık ortamlarda tutarak
3. Önce uygulamanın temel işlevini, daha sonra sınır hallerini ve en son olmaması gereken durumları test ederek
4. İlk olarak uygulamadaki en son değişiklikleri test ederek
5. İlk olarak temel fonksiyonları test ederek
6. Beceriyi güvenilirlikten önce test ederek
7. Herkesin yöntemlerini, bazılarının yöntemlerinden önce test ederek
8. Genel riskleri, özel durumlarda oluşan risklerden önce test ederek
9. En fazla zarara sebep olacak yerlerden başlayarak
10. Müşteri/Topluluk taleplerini önce test ederek
11. Test sonuçlarını değerlendirip iyileştirici yada önleyici aktiviteler için ekibi zorlayarak
12. Proje tamamlanmış dahi olsa, uygulamayı iyi tanıyan biri olarak, bunun sorumluluğunu hissederek

Saati de göz önüne alırsak, bazı noktaları atlamış olabilirim. Ama yine de bu küçük yazının gündeme getirdikleri ile ilgili içim rahat.

Bir sonraki yazıda görüşmek üzere