Yazılım testleri ikiye ayrılır:

I. Manuel Test: herhangi bir otomasyon aracı kullanmadan yapılan testler

II. Otomasyon Testi: Bir otomasyon aracı kullanılarak yapılan testler

I - TEST TÜRLERİ

1. White Box Testing: Developer test ekibine kodu teslim etmeden önce her kod satırını inceler.

2. Gray Box Testing: Test senaryolarını tasarlamak için dahili kodlamaya erişim içerir. Kodlamayı bilen bir kişi GBT yapabilir.

3. Black Box Testing: Test uzmanı yazılımı gereksinimlere göre analiz edecek, kusur veya hataları belirleyecek ve development ekibine geri gönderecektir. BBT'in temel amacı iş ihtiyaçlarını veya müşteri gereksinimlerini belirlemektir. Diğer bir ifadeyle uygulamanın işlevselliğini kontrol etme sürecidir. Kaynak kodun bu testte görünmemesi yüzünden kara kutu testi olarak da bilinir.

BBT Türleri

A) Functional Tests: Test uzmanı tüm bileşenleri gereksinim özelliklerine göre sistematik olarak kontrol eder.

1. Unit Test: Uygulamanan tek bir modülünün test edilmesidir. Ana amaç, birim bileşenlerini performanslarıyla doğrulamaktır.

2. Integration Test: Bağımlı modüller arasındaki veri akışı veya iki özellik arasındaki arayüzün test edilmesidir. Amaç her modül arasındaki ifadenin doğruluğunu test etmektir.

3. System Test: Uçtan uca test olarak da bilinir. Yazılımın her özelliğinden geçilir ve son özelliğin iş gereksinimlerine göre çalışıp çalışmadığı test edilir.

4. Regression Test: En yaygın kullanılan ve otomasyon araçları için en uygun testtir. Developer bir hata düzelttiğinde bunun diğer özellikleri etkileyip etkilemediğinin anlaşılması için yapılır. Herhangi bir değişiklik talebi, yeni bir modül eklenmesi veya bir hatanın düzeltilmesinden sonra yapılır.

5. User Acceptance Test (Kullanıcı Kabul Testi): Müşteriler tarafından nihai ürünü kabul etmedene önce yapılır. UAT'de gerçek zamanlı iş senaryoları UAT adı verilen farklı bir ortamda analiz edilir.

6. Explotary Test (Keşif): Uygulama mümkün olan her şekilde incelenir ve bir test belgesi oluşturulur. Uygulamanın akışı anlaşılır ve test edilir.

B) Non-Functional Tests: İşlevsel olmayan testler (non-functional) yazılımın üretim riskini ve ilgili maliyetleri en aza indirmemize yardımcı olur. Bu testler performans, yük, stres, kullanılabilirlik ve uyumluluk testlerinin bir kombinasyonudur.

1. Documentation Test:

2. Installation Test:

3. Performance Test: Uygulamanınn çalışması bir miktar yük uygulanarak test edilir. Test uzmanı sadece tepki süresi, yük, ölçeklenebilirlik, yazılımın veya uygulamanın kararlılığı gibi yönlere odaklanır.

a) Load Testing (yük): Yazılımın en yüksek çalışma hacmini ve darboğazlarını tespit etmeye yardımcı olur.

b) Stress Testing: Yazılımın yüksek trafikte veya yüksek miktarda data işlemesi gibi durumlarda nasıl çalıştığını görmek için aşırı iş yükü altında çalışması incelenir. Amaç uygulamanın kırılma noktasını belirlemek ve hangi noktada cevap veremediğini tespit etmektir.

c) Scalability Testing (ölçeklenebilirlik): Uygulamanın yükünün belirli ölçülerde arttırılarak veya azaltılarak performansın test edilmesidir. Bu testle sistemin süreçlerin veya veritabanının yukarı doğru bir ihtiyacı karşılama yeteneği kontrol edilir.

d) Stability Testing (Stabilite): Bu testte yük belli bir süre boyunca uygulanarak uygulamanın performansı değerlendirilir. Uygulamanın sabitlik problemleri ve verimliliği kontrol edilir.

e) Usability Testing (Kullanılabilirlik): Uygulamanın kullanıcı dostu olup olmadığı analiz edilir ve son kullanıcı arayüzündeki hatalar bulunur.

f) Compliance Testing (Uyumluluk): Belirli bir donanım ve yazılım ortamında bir uygulamanın işlevselliği kontrol edilir. Uygulama farklı işletim sistemleri ve tarayıcılarda test edilir.

g) Diğer Test Türleri

- Smoke Test (duman): Gerçek test sürecine geçilmedin önce uygulamanın temel ve kritik özellikleri test edilir.

- Sanity Test: Mecut bir yazılımın yapısına eklenen yeni modüllerin bir sonraki test düzeyine geçmek için yeterince kararlı olup olmadığına belirlemek için yürütülür..

4. Reliability Test:

5. Security Test: Dışarıdan gelen kötü amaçlı saldırılardan kaçınabilmek ve uygulamanın güvenliğini sağlayabilmek amacıyla uygulamadaki zayıflık, risk ve tehditlerin belirlenmesine yönelik testtir. Veri güvenliği önceliğine dayanır.

II - TEST TİPLERİ

1. Positive Testing (Happy Path): Varsayılan bir çıktıyı oluşturmak için uygulamayı pozitif bir akışla test etmek için kullılır. Genellikle uygulama üzerinde yapılacak ilk test şeklidir. Pozitif test kategorisine girer. Uygulamanın müşteri gereksinimlerine göre test edilmesidir. Genellikle E2E (Enterprise-to-Enterprise) testlerinin bir parçasıdır. Uygulamayı bozmayı veya istisna yollarını çalıştırmayı amaçlamaz. Ürünün kalitesini garanti etmez çünkü sadece pozitif senaryolarla fonksiyonalite test edilir.

2. Negative Testing: Kullanıcının yazılım uygulamasına kasıtsız veya beklenmeyen bir veri girdiğinde yazılımın anormal davranması önlemek için gerçekleştirilir. Amaç yazılıma beklenmeyen veriler girildiğinde yazılımın nasıl tepki verdiğini ölçmek ve bu durumda bile uygun performansla çalışmasını sağlamaktır. Yüksek performanslı yazılım geliştirmede önemli rol oynar. Ör. Geçersiz bir kullanıcı adı, şifre vs girildiği zaman uygun hata mesajları ve yönlendirmeler yapılıyor mu? Negatif test geliştirilirken olası olumsuz senaryolar hesaba katılmalı ve güvenlik açıkları ortadan kaldırılmalıdır.

3. Risk-Based Testing: Risk, bir projenin ölçülebilir başarı kriterleri üzerinde olumlu veya olumsuz etkisi olan belirsiz bir olayın meydana gelmesidir. RBT, risk olasılığını merkeze alan bir yazılım test türüdür. Hata olasılığı ve yüksek riskli alanlar belirlenir; risk bazlı test süreci tanımlanır, önce en yüksek risk ögeleri test edilecek şekilde tasarlamak için uygun test yaklaşımı ve test tasarım teknikleri uygulanır.

Risk-Based Testing Süreci: Risk tanımlama, Risk analizi, Risk tepkisi, Test kapsamı, Test süreci tanımı

4. Static Testing: Kodu çalıştırmadan uygulamayı kontrol eden testtir. Bu testler bir doğrulama sürecidir.

Statik Testte Neler Test Edilir: Birim test durumları, İş gereksinim dokümanı, Use-Cases, Sistem/fonksiyonel gereksinimler, Test verisi, Kullanım/Eğitim klavuzu, Test planlama strateji belgesi, Otomasyon/Performans test skriptleri

5. Dynamic Testing: Kod çalışma ortamında yürütülen testtir. Fonksiyonel ve fonksiyonel olmayan testlerin gerçekleştirildiği bir doğrulama sürecidir. Dinamik testin amacı yazılımın iş gereksinimlerine uygun olarak çalıştığını doğrulamaktır. Zaman, para ve insan kaynağı açısından maliyetli bir süreçtir.

III - TEST TEKNİKLERİ

Test Senaryosu Nasıl Belirlenir: Kapsam belirlenmeli, Senaryonun dayandığı sistem hakkında bilgi, Yazılım geliştirme sürecinin düzenlenme şekli, İlgili kişilerin bilgi ve deneyimleri, Testleri yürütmek için mevcut zaman ve bütçe vb dikkate alınmalıdır.

1. Specification-Based / Black-Box Techniques

- Equivalence Partitioning: Aynı niteliklere sahip girdiler bölümlere ayrılır. Test kullanıcıları kodu görmez. Amaç, test senaryolarını yürütmek için tüm olası senaryoları kapsayan her bölümden bir koşul seçmektir. Ör.

1-10 ve 20-30 arası inputları kabul eden bir program varsayalım.

5 farklı senaryo vardır: --0 (invalid), 1-10 (valid), 11-19 (invalid), 20-30 (valid), 31-+ (invalid)

Input için seçilebilecek değerler: 0, 3, 15, 25, 45

- Boundary Value Analysis (sınır değer analizi): Senaryoların sınırlardaki değerleri içerecek şekilde tasarlandığı testlerdir. Ör. Otel/Restoran/Bilet rezervasyonu Ör. 0,1,2,9,10,11,19,20,30,31

- Decision Table Testing (karar tablosu): Karar Tablosu koşulların test eylemlerine karşı bir tablo halinde temsilidir. Koşullar girdi, eylemler çıktı olarak kabul edilir. Karar tablosu sebep-sonuç tablısu olarak da adlandırılır. DTT Oluşturma: Girdiler satır halinde listelenir, Sütuna tüm kurallar yerleştirilir, Tablo farklı girdi kombinasyonlarıyla doldurulur, Son satırda çıktı bir girdi kombinasyonu olarak not edilir

- State Transition Diagrams (durum geçiş şemaları): Bir dizideki farklı giriş koşulları için test edilen bir uygulamanın davranışını analiz eder. Hem + hem - giriş testi değerleri sağlayabilir ve sistem davranışı kaydedilebilir. Aynı girdi için farklı çıktı aldığınız bir sistem sorunlu bir sistemdir.

- Use Case Testing (durum testi): İşlevsel bir test tekniğidir, yani programlama becerisi gerekmez. Test uzmanının her işlemin başından sonuna kadar tüm sistemde hangi test komut dosyalarının yürütüldüğünü belirlemesine yardımcı olur.

2. Structure-Based / White-Box Techniques

- Statement Coverage / Line Coverage: Kaynak koddaki her ifade en az bir kez yürütülür. Büylece kaynak kodun ne olduğu ve ne yapması beklenmediği kontrol edilmiş olur. Ancak kaynak koddaki yanlış koşul test edilemez.

- Condition Coverage / Predicate Coverage: Koşul kapsamı tüm boolean ifadelerinin kapsanıp kapsanmadığını ve hem doğru hem de yanlış olarak değerlendirilmesini sağlar.

- Decision Coverage / Branch Coverage: Bir karardaki her koşulun en az bir kez olası tüm sonuçlarını üstlenmesi ve bir programa veya alt programa her giriş noktasının en az bir kez çağrılabilmesi için yeterli test senaryosunu gerektirir. Yani her dal ya doğrudur ya da yanlıştır. Tüm olası durumlar en az bir kez çağrılır.

- Multiple Condition Coverage: Bir kararla ilgili koşullar ihin her doğru ve yanlış kombinasyonu mutlaka test edilmelidir.

3. Experience-Based Techniques

- Exploratory Testing: Genellikle alanın uzmanlarınca uygulanır. Gereksinimler hakkında bilgi sahibi olmadan, sadece uygulamanın işlevleri keşfedilerek gerçekleştirilir.

- Error Guessing: Test uzmanının önceki deneyimine dayalı olarak yazılımdaki hataları bulmak için kullanılan bir tekniktir. Hata tahmininde belirli kurallar uygulanmaz. Test uzmanının tecrübesi çok önemlidir.