Akıllı telefonlar, kameralar, IoT cihazlar, bilgisayarlar, arabalar ve bunlar gibi birçok teknolojik cihaz günlük hayatımızın ayrılmaz birer parçası oldu. Kullanımı kolay, kullanıcı dostu, genellikle mükemmel çalışan ama bazen bizleri sinirlendiren bu cihazlar, kullanıcılara ulaşana kadar bir sürü aşamadan geçiyor. Bu yazıda değineceğimiz konu, bu aşamalardan bir tanesi; gereksinimlerin ve kalitenin sorgulandığı aşama olan test.
Test, üretilen ürünün belirlenen gereksinimleri karşılayıp karşılamadığının ve ürünün doğru çalışıp çalışmadığının kontrolü olarak tanımlanabilir. Test denildiğinde doğrulama ve geçerli kılma kavramları akla gelmektedir. Sürekli karıştırılan bu kavramlar birbirine benzemekle birlikte birbirinden farklıdır. Doğrulama; üretilen ürünün doğru çalışıp çalışmadığının kontrolüdür. Geçerli kılma ise; üretilen ürünün doğru ürün olup olmadığının kontrolüdür. Bir ürün mükemmel bir şekilde çalıştığı halde, müşterinin istediği ürün değilse, müşterinin ihtiyacını karşılamaz. Aynı durum müşterinin istediği şekilde üretilen ama doğru çalışmayan ürün için de geçerlidir. Bu nedenle doğrulama ve geçerli kılma kavramları birbirinden farklı ama birbirinden ayrılamayan kavramlardır.
Temel hedeflerinden bazıları hataları bulma ve önleme, gereksinimlerin sağlanıp sağlanmadığının kontrolü, ürün kalitesi ve yeterliliği hakkında bilgi sağlama olan test, projenin en önemli aşamalarından biridir. Bu nedenle; son 50 yıldır test (özellikle yazılım testi) üzerinde önemli çalışmalar yapılmaktadır. Bu süre boyunca test hakkında belirli prensipler ortaya çıkmıştır. Bu prensiplerin ortak noktalarını bir araya getiren ve en çok kabul gören prensipler “Yedi Test Prensibi” başlığı altında toplanmıştır. Bu prensipler daha çok yazılım testi için ortaya çıkmış olsa bile tüm ürün için kabul edilen prensiplerdir.
7 Test Prensibi:
1) Test, üründe hata olduğunu gösterir. (Testing shows presence of defects): Test aktiviteleri, üründe hata olduğunu kanıtlar. Doğrulama ve geçerli kılma aktiviteleri, üründeki hata sayısının azalmasına yardımcı olur. Ancak, bu durum üründe hata olmadığı anlamını taşımaz. Üzerinde çok sayıda test yapılmış olan bir üründe bile hata ortaya çıkar. Ve unutmamak gerekir ki; bir kullanıcı, ilk birkaç denemesinde sizin test etmediğiniz bir hatayı bulabilir.
2) Teste proje sürecinin başında başlamak gerekir. (Early testing): Hataların erken tespit edilmesi, maliyetlerin ciddi oranda azalmasını sağlamaktadır. Bu nedenle, test aşamasına projenin başından başlamak gerekmektedir. Erken fark edilen her hata daha hızlı düzeltildiği gibi aynı hatanın tekrarlanmasını da engeller.
3) Hatalar belirli yerlerde yoğunlaşır. (Defect clustering): Yapılan araştırmalar, hataların büyük çoğunluğunun, küçük bir kısımda bulunduğunu göstermektedir. Bu duruma, Pareto prensibi veya 80-20 kuralı denmektedir. Hataları %80’i ürünün %20’lik bir bölümünde bulunmaktadır. Bu kural dikkate alınarak yapılan testlerde, hataların büyük bir çoğunluğu daha kısa sürede bulunabilir. Bu prensip için bir alt başlık açmak doğru olacaktır. Test sorumlularının, geliştiricilere göre test strateji belirlemesi gerekebilir. Yapılan araştırmalara göre kişiler belirli konularda sürekli olarak aynı hataları yapmaktadır. Bu nedenle, bir geliştiricinin yaptığı tüm ürünlere bakıldığında, geliştiricinin genel olarak aynı yerlerde hata yaptığı/yapabileceği sonucu çıkartılabilir. Test stratejisi belirlenirken, geliştiricinin geçmiş projelerine bakılması ve buna göre bir değerlendirme yapılması, hataların bulunmasını kolaylaştıracaktır.
4) Antibiyotik direnci (Pesticide Paradox): Sürekli aynı test senaryoları kullanılarak yapılan testlerle bir süre sonra hata bulunamaz. Bu durum grip tedavisine benzer. Sürekli kendini geliştiren ve bir önceki antibiyotiğe dayanıklı hale gelen grip mikrobu için her seferinde antibiyotiğin geliştirilmesi gerekmektedir. Aynı durum test için de geçerlidir. Hatalar bulunduktan ve düzeltildikten sonra var olan testler yeni hatalar bulamayabilir. Bu nedenle, test senaryolarının sürekli olarak gözden geçirilmesi, güncellenmesi ve yeni test senaryolarının tanımlanması gerekmektedir.
5) Bir ürünü %100 test etmek imkânsızdır. (Exhaustive testing is impossible): Projedeki tüm girdi ve çıktıları, bunların birbirleri ile olan kombinasyonlarını test etmek imkânsızdır. Tabi, sonsuz bir süreniz, çok büyük bir bütçeniz ve çok sabırlı bir testçiniz varsa durum değişir. Sonuçta; zor hemen yapılır, imkânsız biraz zaman alır. Ama buradaki önemli noktalar; ne kadar zaman ve ne kadar bütçe sorularıdır.
Basit bir örnekle üzerinden geçelim. Örneğin, Karel YT500 telefonun bir penceresine bakalım:
Sizce, uygulama arayüzündeki bir pencerede yer alan 11 tane işaret kutusunu test edebilmek için kaç tane test senaryosu yazılmalıdır? Cevap veriyorum: Çok, oldukça çok. İşaret kutularının birbirinden bağımsız test edilmesi gerekmektedir. İşletim sistemi bağımsız bir şekilde, arayüzde yer alan 11 tane işaret kutusunu test etmek için gerekli olan test sayısı 2^11=2048’dir. Bu testlerin Linux, Windows7, Windows10… gibi işletim sistemlerinde tekrarlanması gerektiği durumda test sayısı oldukça artmaktadır. Tüm testlerin yapılması imkânsızdır. Burada dikkat edilmesi gereken nokta tüm testlerin yapılması değildir. Dikkat edilmesi gereken nokta; test süresi ve bütçesi dahilinde en çok sayıda hatanın bulunmasıdır. Test sorumlusunun doğru test stratejilerini belirlemesi ve az sayıda test ile en çok sayıda hatanın bulunmasını sağlaması gerekmektedir. Ve ne yazık ki, hiçbir şey göründüğü kadar kolay değildir.
6) Test yaklaşımı projeye göre değişiklik gösterir. (Testing is context dependent): Belirlenecek olan test stratejileri, yapılacak olan testler projeden projeye farklılık gösterir. Bu nedenle, test her proje için ayrı ele alınmalıdır. IoT uygulaması için belirlenecek olan test stratejileri ve yapılacak olan testler ile aviyonik projeleri için belirlenecek olan test stratejileri ve yapılacak olan testler birbirinden tamamen farklıdır. Bir projede performans ön planda olurken diğeri için güvenlik ön planda olabilir.
7) Hata bulunamadığı için ürünün hatasız olduğunu düşünmek (Absense of errors fallacy): Testler başarıyla bitirildikten ve bulunan hatalar düzeltildikten sonra üründe hiç hata çıkmayacağı, ürünün müşteri ihtiyaçlarını karşılayacağı düşünülür. Ama ne yazık ki durum öyle değildir. Tüm testlerin yapılması mümkün olmadığı için, her zaman hata çıkma olasılığı vardır. Bakınız Prensip 1: Kullanıcı, ilk birkaç denemesinde sizin test etmediğiniz bir hatayı bulabilir.
Bu yazıyı okuyanlar, bunları da okudu;
Temiz Kod İçin 15 Öneri
Hareket Algılama Nedir ve Nasıl Çalışır?
Farkında Olmadan Kullandığımız 10 Teknoloji
