Yazılım Test Prensipleri Nelerdir ?
Test nedir ?
Ortaya çıkarılacak ürünün beklenen seviyede olduğunu belirlemek , yada istenilen ölçüye ulaşmasını sağlamak için belli prosedürler dahilinde gerçekleşen sürece denir.
İlgili bir veya daha fazla özelliği değerlendirmek için yazılımların veya sistemlerin bileşenlerinin manuel veya otomatik araçlar kullanılarak yürütülmesini içerir.
Amacı, müşterinin gereksinimlerini karşılamak, ürünün kalite düzeyine karşı güven oluşturmak, kusurları önlemektir. Düzgün bir şekilde test edilen yazılım ürünü güvenilirlik, güvenlik ve yüksek performans sağlar ve bu da zaman tasarrufu, maliyet etkinliği ve müşteri memnuniyeti ile sonuçlanır.
Testin amacını anlamayıp , test hakkındaki efsanelerden olan; test etmek zaman alır, test etmek çok pahalı gibi mitlere örnek verecek olursak:
İlk gezegenler arası meteoroloji uydusu olarak planlanan ve Mars’ın yörüngesinde dolanması tasarlanan “Mars Orbiter” 1999'da kayboldu. NASA ekibi hesaplamada İngiliz ölçü birimini, 125 milyon dolarlık uydunun sipariş edildiği şirket de uydunun yazılımında metrik sistemi kullanmıştı. Uydunun Mars’ın atmosferinde parçalandığı sanılıyor. Belki de test edilseydi bugün aramızda olacaktı kim bilir…
Başka bir yazımda, yazılım neden başarısız olur, error-fault-failure ve test edilmeyen yazılım ürünlerinin hakkında örnekler vereceğim. Yazımın asıl amacına dönmek gerekirse, test süreçlerinin dayandığı 7 temel prensipten bahsedeceğim. Bu prensipler, yazılım test uzmanlarının zamanlarını etkin bir şekilde kullanmaları ve yazılım test süreci sırasında zihniyetlerini şekillendirmeleri için gereken genel bir kılavuz olarak gösterilebilir.
1 — Testing Shows Presence of Defects
Yapılan testler yazılım ürünündeki kusurların yokluğunu değil varlığını gösterir. Bir üründe hata bulunamaması yazılımın hatasız olduğu anlamına gelmez.
Testler daha fazla hata bulmak için test edilmelidir. Test, bir sistemde bulunan keşfedilmemiş hataların olasılığını önemli ölçüde azaltır. Ancak birden fazla test tasarlansa bile, “bu yazılım hatasızdır” iddiası yanlış olacaktır.
2 — Exhaustive Testing is Impossible
%100 kapsamlı test imkansızdır. Nedenine ise ISTQB eğitiminde Alper Buğra Keleş hocamın bir örneğini vereceğim.
Çalışanların yaşlarını girdiğimiz web sayfası olsun. Yaş aralıkları 20–50 olsun. Integer değer alsın : -32,767 den 32,767 ye kadar değer verilebilir ve 65535 ihtimal olur. Buna özel karakter, geçersiz karakterler ve diğer ihtimalleri de (empty value ,spaces) ekleyelim. Yaklaşık 70.000 ihtimal yapar. 70.000 min = 1167 saat = 49 gün sürer .:)
Örneğin, hesap makinesi gibi nispeten basit bir uygulamayı ele alalım. Her bir girdi kombinasyonunun test edilmesi, milyonlarca test senaryosu ve binlerce saat bir test uzmanının yürütmesi zaman alır. Bunun yerine, risk bazlı testler ve önceliklendirme gibi test tekniklerini uygulamanın daha önemli ve daha riskli bölümlerine odaklanmak daha iyi bir yöntemdir.
3— Early Testing
Yazılım üründeki hataları en iyi nasıl önleriz sorusuna, yazılım geliştirme sürecinin en başında başlamak gerekir diyebiliriz. Daha ilk adımdan dökümanları inceleyerek testimize başlayabiliriz.
Hataları gereksinim aşamasında yakalamak daha az maliyetlidir. Amacımız erken test ile hatanın bir an önce tespit edilip bir sonraki sürece geçmesini engellemektir.
Yazılım ürünündeki hata ileri aşamalarda tespit edilirse, bu hatanın geriye dönük maliyeti çok büyük olacaktır. Kısaca erken test zamandan ve paradan tasarruf sağlar. Büyük uygulamalar için zaman kaybı eşittir gelir kaybı diyebiliriz.
4 — Defect Clustering
Yazılım ürününe hatalar yazılımın belli alanlarına yoğunlaşır. Bu prensip, test edilmekte olan sistemdeki kusurların çoğunun birkaç modülde bulunabileceğini belirtir. Pareto analizi veya 80/20 kuralı diyebiliriz. Kusurların yüzde 80'i kodun yüzde 20'sinden kaynaklanmaktadır.
Daha karmaşık bileşenleri veya daha fazla bağımlılığı olan veya en çok değişen alanları belirlemek, testlerdeki bu önemli risk alanlarına yoğunlaşarak, modüllerde kümelenen hatalar tespit edilebilir.
5 — Pesticide Paradox
Yazılım ürününde sürekli aynı testleri koşarak hata bulmaya çalışmak. Başlangıçta bazı kritik hataları bulunacaktır, fakat daha sonra kusurları bulmayı bırakacaklar ve bir süre sonra testlerin etkinlikleri eskisi kadar yüksek olmayacak. Aslında ben bunu kendim bir bağlamda yazılım geliştirme prensibi olan DRY( Don’t repeat yourself ) ile benzer mantığa sahip diye düşünüyorum.
Bu paradoxa girmemek için test senaryolarımızı sürekli gözden geçirmeli ve yenilemeliyiz. Pesticide paradoksunun oluşmasını önlemeye yardımcı olmak için paralel olarak çeşitli test teknikleri, yöntemleri ve yaklaşımları kullanmalıyız ve mümkünse yeni senaryolar yazılıp koşulmalıdır.
6 — Testing is Context Cependent
Her yazılımı testi aynı şekilde test edebilir miyiz ? Oyun yazılımını, hastane yazılımı ile aynı şekilde test edemeyiz. Uygulama türüne bağlı olarak farklı bir yaklaşım, metodolojiler, teknikler ve test türleri kullanmalıyız.
Her yazılım ürünü farklı içeriklere sahiptir, temel olarak, bir e-ticaret sitesini test etme şeklimizle, bir API uygulaması veya bir veritabanı raporlama uygulamasının test edilmesi farklıdır ve farklı test türleri ve yaklaşımları gerektirir. Test ettiğimiz bir çok farklı uygulama her zaman yaklaşımımızı etkileyecektir.
Örneğin ilk defa çalışacağımız bir alanda uygulama hakkındaki dökümanları inceleyip gereksinimleri anlamalıyız. Daha önce kullanılan test metodolojileri ve stratejilerine ait dökümanları gözden geçirmeliyiz ve buna göre projeye plan çizmeliyiz.
7 — Absence of Errors Fallacy
Yazılımda hata kalmadığının düşünülmesi en büyük yanlıştır. Testler uygulamalardaki hataların tümünü önleyemez , tüm hataları tespit edemezler ve ürünün hatasız olduğunu kanıtlayamazlar. Yazılım testi sadece kusurları bulmak için değil, aynı zamanda yazılımın gereksinimleri karşılayıp karşılamadığını da kontrol etmek içindir.
Test, yalnızca bir yazılım parçasında kusurların bulunduğunu gösterir. Kusursuz olduğundan değil. Her şeyi test edemeyiz. Yani tüm kusurların keşfedilmiş olması mümkün değildir. Hata ortaya çıkmak için farklı bir durum bekliyor olabilir. Yapabileceğimiz şey, paydaşlara nihai ürünün gereksinimlerinin karşılandığına ve ürünün kalite düzeyine dair güven sağlamaktır, ve bilinen kusurları olmayan yüksek kaliteli bir ürün sunmaktır.
Yazılım test alanında 7 temel prensipler kısaca böyle, bu prensipler kaliteli ve kusurları bulunmuş, gereksinimleri tam anlamıyla karşılayan bir ürün çıkarmamıza yardımcı olur.
ISTQB eğitimiyle bana bu alanda ilk bilgiyi aşılayan Alper Buğra KELEŞ ‘ e çok teşekkür ediyorum…