Test Tasarım Teknikleri
Herkese merhabalar. BDD, Gauge ve Test Otomasyon serisine devam etmeden önce arada bahsetmek istediğim bir konudan sizlere bahsediyor olacağım. Zira bu arada bahsedeceğim konu, bir otomasyon projesinden önce her yazılım test uzmanının hakim olması gereken bir konudur diye düşünüyorum. Çayımız, kahvemiz hazırsa başlayalım ..:)
Test tasarım teknikleri, test koşumu yapmadan önce test verilerini, test senaryolarını ve test şartlarını belirlemektir. Yazılım testinde, test tasarım teknikleri iki ana kategoride sınıflandırılabilir: Statik ve Dinamik test teknikleri. Gelin biraz bu kategorilerden söz edelim.
Statik Test Tasarım Teknikleri
Statik test, kod yürütülmeden kodun veya test dökümanlarının manuel olarak gözden geçirilme sürecidir. Statik testler dinamik testlere geçilmeden önce yapılmalıdır. Bunun sebebini Statik ve Dinamik testleri ayrıştırmaya başladığımızda daha iyi anlayacağız. Projeye başlamadan önce gözden geçirme yoluyla tespit edilen hatalar veya bulgular erken zamanda çözülmesiyle ileride yaşanacak bir sorundan daha az maliyete sebep olacaktır. Burada bahsettiğimiz maliyet zaman, ödeme sistemi hatasından kaynaklı maddi anlamdaki maliyetler, kullanıcılar tarafından ürüne karşı oluşabilecek güven zafiyeti gibi birçok maliyete sebep olabilmektedir.
Statik Test Tekniklerini başlıklar altında toplayalım.
Gözden Geçirme(Review)
- Gayri resmi gözden geçirme.
- Ürünü geliştiren kişilerden farklı kişilerin, bağımsız olarak kodu incelemesi.
- İnceleme sonucunda bulunan hatalar veya bulgular ürünü geliştiren kişilere bildirilir. Bu sayede farklı bir açıdan gözden geçirilme yolu ile ürüne ait kalite oranı artırılmasına yardımcı olur.
Üzerinden Geçme(Walkthrough)
- Planlı olarak ürünü gözden geçirece kişilere sunulması işlemidir.
- Küçük ölçekli işler için geçerli olup herhangi bir ön hazırlık gerektirmez.
Teknik Gözden Geçirme (Technical review)
- Ürünü geliştiren kişilerin plansız şekilde ürünü gözden geçirme işlemidir.
- Sonuçlar alınır ve kaydedilir.
- Sonuçlara göre iyileştirme gerekiyorsa iyileştirmeler sunulur.
Teftiş (Inspection)
- Ürünü geliştiren kişilerden farklı benzer birikime sahip kişilerin ürün yayımlanmadan önce yürüttüğü resmi gözden geçirme sürecidir.
- Toplantıyı moderatör eşliğinde gerçekleştirirler.
- Planlı şekilde düzenlenir ve gözden geçirecek kişiler ön hazırlıkta bulunurlar.
- Olası hatalar saptanmaya çalışılır.
Statik Test Analizi(Static Analysis)
- Statik analiz ürünün, çoğunlukla çeşitli araçlar kullanılarak test edilmesidir.
- Amaç clean kod yazmak için gerekli kriterlerin sağlanmasını kolaylaştırmaktır.
- Bahsedilen kriterler; Kodlama standartlarına uygunluk, Kod tekrarından kaçınma, Birim testlerinin yeterliliği, Karmaşıklığın doğru dağılımı, Spagetti olmayan tasarım ve Yeterli yorum frekansı.
Dinamik Test Tasarım Teknikleri
Yukarıda bahsettiğimiz gibi statik test sürecinde kod çalıştırılmadan ürün, döküman ve veri üzerinden incelemeler yapılıyordu. Dinamik test sürecinde kod çalıştırılır, belirli teknikler kullanılır ve sonuçları gözlemlenerek raporlanması yapılır.
Dinamik Test Tasarım Teknikleri, Black Box Testing, White Box Testing ve Tecrübeye Dayalı Test şeklinde üç kategoride ele alınır. Şimdi bu dinamik test tasarım tekniklerini başlıklar altında inceleyelim.
Kara Kutu (Black Box Testing) Test Teknikleri
Denklik Paylarına Ayırma
Denklik paylarına ayırma test tekniğinin amacı, benzer özelliklere sahip test senaryolarını gruplandırarak daha az test senaryosu yazmaktır. Bu tekniğe göre aynı çıktıyı veren test girdileri için bir tane test senaryosu yazılması yeterlidir. Bu teknik bütün test seviyelerinde uygulanabilir. Bir örnekle bu tekniği açıklamaya çalışalım.
Doğum tarihi hesaplama uygulaması olsun elimizde. Bu uygulama şu şekilde çalışıyor. Bir input alanı var elimizde ve input alanının üstünde 1–120 arasında bir değer girin title’ı bulunuyor. Input alanının yanında ise hesapla butonu bulunmakta. Kullanıcı hesapla butonuna bastığında kullanıcının yaşına göre doğum yılı bulunmak istenmektedir. Bu örneği denklik paylarına ayırma tekniğine göre ele alacak olursak, geçerli ve geçersiz bütün test girdilerinin aşağıdaki gibi olduğunu söyleyebiliriz;
- Geçersiz Aralık: 0 ve 0’dan küçük sayılar
- Geçerli Aralık: 1–120 arasındaki sayılar
- Geçersiz Aralık: 121 ve 121’den büyük sayılar
Denklik sınıflarının doğru şekilde belirlenmesi, test tasarımımızı dolayısıyla yapacağımız testlerin kalitesini olumlu şekilde etkileyecektir.
Sınır Değer Analizi
Sınır Değer Analizi tekniği bütün test seviyelerinde uygulanabilir bir tekniktir. Uygulaması kolay olan bir tekniktir fakat hata bulma olasılığı oldukça yüksektir. Bu teknik özellikle Denklik Paylarına Ayırma tekniği ile birlikte uygulanırsa ortaya harika sonuçlar çıkmaktadır ve daha etkili sonuçlar elde edilebilmektedir.
Sınır değer analizini yine doğum tarihi hesaplama uygulaması üzerinden bir örnekle açıklamaya çalışalım.
Sınır değer analizi tekniğinde görüldüğü üzere bir sınır değerinin testi için 3 farklı test senaryosu yazılabiliyor.
Karar Tablosu Testi
Karmaşık iş kurallarına sahip sistemlerin test edilmesinde kullanılan bir test tekniğidir. Karar tablosu test tekniğinin en büyük avantajı, test sırasında gözden kaçabilen olasılıkların net bir şekilde listelenerek gözden kaçırma olasılığını en düşük seviyeye çekmektedir.
Bir örnekle açıklamak gerekirse, basit bir kullanıcı adı ve parola alanlarının olduğu bir login ekranının testini ele alalım. Bu alanda kullanıcıdan input alanlarına kullanıcıya ait kullanıcı adı ve parola girmesi beklenmektedir. Ardından login butonuna tıklayarak içerisinde bulunduğu sisteme login olması beklenmektedir.
Kullanım Durum Senaryosu Testi
Kullanım durum senaryoları sistem ile aktör arasındaki etkileşimi göstermek için yazılan senaryolardır. Kullanım durum senaryosu testinin amacı, sistemin uçtan uca her bir senaryonun teker teker bütün sistemi kapsayacak şekilde test etmesidir. Kullanım durum senaryolarında ana senaryo ve alternatif senaryolar bulunur. Ana senaryoda sistemin yerine getirmesi gereken adımlar yer almaktadır. Alternatif senaryolarda ise sistemin uç noktaları için senaryolar yer alır.
Durum Geçiş Testi
Durum geçiş testinin amacı, belirli iş kurallarına bağlı olarak oluşmasını ve bir durumdan diğerine geçerek bir noktada sonlanması durumunu test etmektir. Bu tür sistemlerde durumlar geçiş diyagramları ile gösterilir.
Beyaz Kutu(White Box)Test Teknikleri
Beyaz kutu testleri, geliştirilen sistemin kod yapısı bilinerek gerçekleştirilen test tasarım tekniğidir.
Beyaz kutu testleri geliştirilen sistemin iç yapısı ve iş akışları ile ilgilenirken, kara kutu testleri sistemin işlevselliği ile ilgilenir. Beyaz kutu test tasarım tekniği, veri akışlarına, kontrol akışlarına, ifade kapsama, dal kapsama gibi konulara odaklanır.
Beyaz Kutu Test Tasarım Tekniğinin Avantajları
- Kod içerisindeki gereksiz satırlar temizlenerek okunuşu kolay clean kod yazılmasını sağlar.
- Kod içerisindeki mantık hataları kolayca tespit edilerek hatalar giderilir.
- Kod optimizasyonu yapılarak daha güvenilir, bakımı kolay, performansı yüksek kod yazılmasını sağlar.
- Kaynak kodun analizi sayesinde olası hatalar geliştirme aşamasında yakalanır.
- Yazılan kodun kod yazma prensiplerine uygun olup olmadığı anlaşılır.
Beyaz Kutu Test Tasarım Tekniğinin Dezavantajları
- Beyaz kutu test tasarım tekniği her ne kadar kodun iç yapısını incelese de kod içerisinde hatalar çıkmaya devam edebilir, %100 test edilmesi imkansızdır.:)
- İş akışında meydana gelen hataları tespit etmekte yetersiz kalır.
- Birim test yazmak karmaşık ve maliyetli bir iştir.
Birim Test(Unit Testing)
Birim test, genellikle bir uygulamada gerçekleştirilen ilk testtir. Uygulamada metot ve fonksiyon gibi en küçük birimler test edilir. Birim testler, yazılım geliştirme ekibi tarafından gerçekleştirilir. Birim testler sayesinde hatalar anında tespit edilerek kod bütününe kaliteli kod merge etmemizi sağlar.
İfade Kapsama(Statement Coverage)
İfade kapsama sağlayabilmek için, sistem içerisindeki her bir satır kodun testler sırasında en az bir kez çalıştırılmış olması gerekmektedir. Böylece her bir ifadenin, uygulamanın çalışmasına olumsuz etki yapıp yapmadığı kontrol edilir. İfade kapsamayı sağlamak için İfade Kapsama = (Yürütülen ifade sayısı / Toplam ifade sayısı) * 100 formülü kullanılır.
Bu formülü bir kod örneği ile açıklamak gerekirse, girdi olarak verilen iki sayı değerinin hangisinin daha büyük olduğunu ifade eden bir kod parçacığı ile örneklendirelim.
Örneğimizde x sayısı y sayısından büyük olduğu için if bloğuna girecektir. Bu durumda 4 ifade kapsama sağlanmıştır. Formülde yerine yazacak olursak; (4 / 6) * 100 = %66 ifade kapsama sağlandığını görebiliriz.
Karar / Dal Kapsama(Desicion/Branch Coverage)
Karar kapsama, bir kontrol yapısının sonucunun hem doğru hem de yanlış olduğu durumları analiz eder. Testlerde karar kapsamının %100 olabilmesi için her iki kararın da ayrı ayrı ele alınması gerekmektedir. Karar kapsamayı hesaplayabilmek için Karar Kapsama = (Yürütülen karar sonuçlarının sayısı / Toplam kod karar sayısı) * 100 formülünden yararlanılır.
Karar kapsamayı yine bir kod parçacığı üzerinden örneklendirmeye çalışalım.
Örneğimiz 7 ifade ve 2 dal içermektedir. Kod içerisinde z değeri 33 olacağı için if bloğuna girecektir. Karar Kapsama = (1 / 2) * 100 = %50 olarak hesaplanmaktadır.
z değerine 10'dan küçük bir değer atandığında else bloğuna girecektir ve yine karar kapsama %50 olacaktır. İki dalın test edilmesiyle birlikte karar kapsama %100 olacaktır. Yani koddaki çalıştırılabilen tüm ifadeler en az bir kez çalıştırılmış olacak ve testi gerçekleşmiş olacaktır.
Tecrübeye Dayalı Test Tasarım Teknikleri
Keşif Testi
Keşif testi, test senaryolarının, yazılımın test edildiği sırada belirlenmesidir. Yani önceden hazırlanmış bir test senaryo dökümanı yoktur. Analizin olmadığı veya zayıf olduğu ve zaman kısıtının olduğu zamanlarda gerçekleştirilir. Test uzmanının karar verdiği yöntemlerle yapılır ve isminden de anlaşılacağı üzere yazılımı keşfetmek amaçtır. Yazılımın güçlü/zayıf yanlarını keşfetmek, yazılımın neler yapıp yapamadığını ve neleri yanlış yaptığını öğrenmek amaçlanır
Hata Tahminleme
Yazılıma ait önceki sürümlerinde çıkan hatalar, benzer yazılım uygulamalarında çıkan hatalar ve yazılım ekibinin daha önceki işlerinde yaptıkları hatalar göz önünde bulundurulur. Bu sayede olası hatalar tahmin edilmeye çalışılır. Olası hataların tahmin edilmesi SDLC sürecinde ortaya çıkabilecek maliyetlerden kaçınmamıza büyük olanak sağlayacaktır. Bu tekniğin etkili olabilmesi için, yazılım test uzmanı ekibinin yazılım ve onu geliştiren ekip hakkında bilgi ve tecrübeye sahip olması beklenir.
Kontrol Listeleri
Daha önceki testlerde ortaya çıkan hataların liste haline getirilerek sonrasında kontrol edilmesidir.
Saldırılar
Yazılımın arıza yapmasını amaçlayan test tekniğidir. İlk üç adımda bahsettiğimiz teknikler farklı kombinasyonlar ile denenebilir.
Umarım faydalı bir yazı olmuştur. Yazılım test sürecinde BDD, Gauge ve Test Otomasyon serisinde devam etmeden önce test tasarım tekniklerine hakim olmak otomasyon süreçlerinde çok daha faydalı olacaktır. Test tasarım teknikleri süreç içerisinde dikkate alınarak uygulanırsa, uygulamalarımız daha güvenli, daha kaliteli ve daha kullanışlı olabilir. Teşekkür ederim..:)
