Cevap.

Negatif senaryoların otomasyonu, kapsamlı bir test sisteminin ayrılmaz bir parçasıdır. Bu, sistemin hatalı eylemlere, yanlış verilere, servislerin arızalarına ve diğer olağandışı durumlara karşı dayanıklılığını doğrulayan testlerdir.

Konu geçmişi:

Geçmişte, olumlu senaryolara (happy paths) odaklanılmıştır çünkü bunları otomatikleştirmek ve sürdürmek daha kolaydır. Ancak kalite gereksinimleri arttıkça, pek çok hata özellikle sınır durumlarında, hatalı veya belirsiz şekilde yanlış koşullarda ortaya çıkmaktadır. Bunların manuel testleri hızla geçerliliğini yitirir, oysa otomasyon bozulmaları takip etme olanağı verir.

Sorunlar:

Tüm olası negatif senaryoların tanımlanması ve kapsanması
Hata mesajlarının, işlemin başarısızlığından sonraki sistem durumunun doğrulanması
İş mantığı değişiklikleri sırasında testlerin sürdürülmesi

Çözüm:

Negatif senaryoların belirlenmesi ve sistematik hale getirilmesi (Boundary Value Analysis, Equivalence Partitioning)
Hata mesajlarını, HTTP kodlarını, istisnaları kontrol etmek için özel assert'ler ve doğrulayıcıların kullanılması
Negatif testten sonra sistem durumunun otomatik olarak "temizlenmesi"

Anahtar özellikler:

Hatalar, istisnalar, standart dışı giriş verileri için açıkça belirtilmiş testler
Hata mesajının ve sistemin iç durumunun kontrolü
Yan etkilerin kontrolü: negatif testten sonra sistem tutarlı bir durumda kalmalıdır.

Kandırmaca sorular.

Negatif testte sadece hangi hataların döndüğünü kontrol etmek yeterli mi?

Hayır. Hatanın içeriğinin yanı sıra, hatadan sonra sistem durumunun değişmediğini de kontrol etmek önemlidir (örneğin, hatalı bir kayıt veritabanına eklenmemelidir).

Tüm olası negatif senaryoları otomatikleştirilmeli mi?

Hayır. Sonsuz sayıda negatif senaryo olabilir; en olası ve kritik olanlar ayrılmalı (Boundary Value, Null/Empty, yanlış tür, SQL enjeksiyonları vb.) ve diğerleri hata geldikçe ele alınmalıdır.

Tüm negatif durumlar için aynı işleme kullanılabilir mi?

Hayır. Farklı negatif senaryolar farklı kontroller, istisna işlemleri ve rollback'ler gerektirir; şablon assert'ler yeterli değildir.

Yaygın hatalar ve anti-patterner

Negatif senaryoları görmezden gelmek veya yalnızca "gösteriş" amaçlı olarak kapsamak
Hatanın yetersiz kontrolü (örneğin, sadece 500 kodu kontrol edilmesi, ancak metin veya yan etki kontrol edilmemesi)
Test düşmesinden sonra temizlenmemiş test ortamı

Gerçek hayattan bir örnek

Negatif vaka

Sistemde yalnızca geçerli kayıt senaryoları test edilmektedir. Boş bir e-posta ile kayıt otomatik test edilmemektedir. Sonuç olarak, boş bir e-posta ile kullanıcı kaydının yapılabileceği sorunu yalnızca canlı ortamda fark edilir.

Artılar:

Testlerin basit bakımı
Az sayıda otomatik test ve hızlı bir geçiş

Eksiler:

Kritik hatalar canlı ortama girer
Düzeltme ve geri dönüş maliyetleri artar

Olumlu vaka

Her negatif senaryo (e-posta yok, yanlış format, sql enjeksiyonu) için yeni bir hesabın oluşmadığını ve hata mesajının içeriğini açıkça kontrol eden otomatik bir test bulunmaktadır.