Yazılımda Test Kavramlarına Genel Bakış
Yeni bir yazıyla merhaba herkese.
Bu yazımda sizlerle çalıştığım şirkette katıldığım bir eğitim olan “Yazılımcılar İçin Test” eğitiminde öğrendiklerimi paylaşmak istiyorum. Buradan eğitmenlerimiz Koray Yitmen ve Berk Dülger’e teşekkürlerimi sunuyorum.
Requirement Kavramı
Öncelikle “requirement” kavramından başlayalım. Bir yazılım ürününü geliştirmek için elimizde analiz edilmiş gereksinimlerimiz olmalıdır. Bu gereksinimler kendi aralarında 2 çeşide ayrılmaktadır. Functional ve Non-Functional gereksinimler. Functional gereksinimler “Ne?” sorusunun cevabını veren ve yazılımın fonksiyonalitesi ile ilgili iken, Non-Functional gereksinimler ise “Nasıl?” sorusunun cevabını veren güvenlik, performans, kullanılabilirlik, sürdürülebilirlik ve güvenilirlik gibi başlıklara ayrılır.
Test Seviyeleri
Component Test: Aslında buna daha çok unit test yani birim testi diyoruz. Kodumuzun en küçük iş parçasını test etmemizi sağlayan test türüdür.
Integration Test: Birbirleriyle bağlantılı modülleri bir arada test etmemize olanak sağlayan test türüdür. Genelde unit testlerinin yazılıp ardından entegrasyon testi yazımına geçilir ve ilişkili tüm modüllerin gerçekten beraberce sorunsuz çalışıp çalışmadığına bakılır.
System Test: Performans, güvenlik (Penetration Test) ve yük testlerini kapsar.
Acceptance Test: Sistemin canlıya çıkmasından önce yapılan son test türüdür. Kullanıcı/Müşteri tarafından yapılır.
Regression Test
Yeni yazılan kodların başka yerleri bozup bozmadığını görmek için koşulan testlerdir. Geriye dönük olduğundan daha önce varolan fonksiyonların işlevlerini yerine getirip getiremediğini kontrol etmemizi sağlar.
~Kamu Spotu~
Validation: Build right software
Verification: Build software right
Test Analiz ve Dizaynı
- Test esaslarının gözden geçirilmesi
- Test esaslarının test edilebilirliğini değerlendirilmesi
- Test koşullarının belirlenmesi ve önceliklendirilmesi
- Test senaryolarının tasarlanması ve önceliklendirilmesi
- Gerekli test verisinin belirlenmesi
- Gerekli test altyapısı ve ortamının belirlenmesi
şeklinde sıralanabilir.
Arıza Durumu ve Etki Analizi (Failure Mode & Effect Analysis)
Yazılımda olan/olabilecek sorunların etkisi ve olasılığına puan verip bu puanlar üzerinden bir çeşit risk haritası çıkarma analizi diyebiliriz. Bu puanlama yapıldıktan sonra etki ve olasılığa verilen rakamları çarpıp risk öncelik numarası belirleyebiliyoruz.
Örneğin:
Otomatik ödemelerin gerçekleşmemesi gibi bir risk tanımımız olsun. Bu durumun etkisine 1 ile 5 arasında puan verecek olursak diyelim 4 olsun. Durumun gerçekleşme olasılığına da 1 ile 3 arasında puan verecek olursak diyelim 1 olsun. 4 x 1= 4 puanlık bir risk öncelik numarası verebiliriz. Aşağıdaki şekildeki gibi riskleriniz için bir liste oluşturmak son derece faydalı bence.
Test Teknikleri
- Black-box (Kara kutu)
- White-box (Beyaz kutu)
- Experience-based (Tecrübeye dayalı)
Yazının bundan sonraki kısımlarında black-box test tekniklerine değineceğim ve örnekler üzerinden ele alacağım.
Equivalence Partitioning
Eşdeğer aralık tekniği de denilebilir. Bu yöntemde girdileri aralıklarına göre ayırıp bu aralıklardaki her testin aynı sonucu vermesini beklediğimizden test sayısını ve test yazma eforunu aza düşürmüş oluyoruz. Örneğin bir turizm şirketinin 5 kişiye kadar (dahil) olan tur ücreti kişi başı 1000 TL iken 10 kişiye kadar tur ücreti 900, 15 kişiye kadar olan ücret ise 800 TL.
0–5 => 1000
6–10 => 900
11–15 => 800
Bu örneğe göre testleri 3 parçaya ayırıp tüm değerleri tek tek değil de bu 3 parça içinden birer örnekle testlerimizi yapabiliriz.
Boundary Value Analysis
Equivalence partitioning yönteminde olduğu gibi eşit olan kısımları tek parça gibi düşünüp ayırdığımızda, tam parçaların ayrıldığı yerleri sınır değerler olarak tanımlarız. Bu sınır değerlerin test edilmesi tekniğine verilen isim sınır değer analizi tekniğidir.
Yine yukarıdaki örnekten yola çıkarsak örneğin 6 bir sınır değerdir ve sınır değer olarak test edilmesi gerekir.
Decision Table
Elimizde şu durumda şu olur, ama şu durumlar varsa şu da olur şeklinde bir senaryomuz olduğunda kullanabileceğimiz güzel bir yöntem. Yine ilk örneğimizdeki gibi tur şirketinden bir örnek verelim:
İlk defa firmayı tercih eden yolculara 5% indirim, firmanın eski müşterisi olan ve acente kartı olan yolculara 8% indirim, firmanın eski müşterisi olan ve peşin ödeme yapan yolculara da ekstra 10% indirim yapılıyor olsun. Bir koşul ya sağlanır ya sağlanmaz, dolayısıyla elimizde 2 durum var. 3 farklı çeşit de test koşulu (test case) var. Dolayısıyla 2³’ten 8 farklı durum çıkar ortaya. Tabloyu aşağıdaki gibi oluşturursak:
Benzer ama daha karmaşık senaryolarda oldukça faydalı tablolar çıkartılabilecek bir yöntem olduğunu düşünüyorum.
State Transition
Bu teknik ise durum değişikliklerinde kullanabileceğimiz bir yöntem. Örneğin bir bilgisayar kapalı durumda iken güç düğmesine basıldığında açılması umulur, her şey yolunda ise açılmaya başlar. Yine her şey yolunda giderse son durumda açılmış olur. State Transition’u bu örnek üzerinden bir tablo ile özetlemek gerekirse şu şekilde bir tablo oluşturmalıyız:
Use Case Testing
Use Case yöntemi sistem ve kullanıcının etkileşimini senaryo halinde yazdığımız bir test şeklidir. Yine tur şirketinden bir örnek verelim. Kullanıcının, tur şirketinin web sitesinin kullanıcı giriş ekranında olduğunu düşünelim:
Burada happy path yani her şey yolunda giderse koşulacak adımlar ilk grafikte, kullanıcının ya da sistemin vereceği farklı tepkilerle çeşitlenen durumlar da 2. grafikte yer almaktadır. Kullanıcı ekranda iken e-posta adresi doğrulanamazsa E1'e parola girdikten sonra parola gücü yeterli bulunamazsa E2'ye sıçrama olur.
Benim şimdilik anlatacaklarım bu kadar. Yazının geliştirilmesi gereken kısımları var ise yorumda belirtirseniz mutlu olurum. Esen kalın.
Elif
