Test senaryosu yazma rehberi: gereksinimden çalıştırılabilir teste

İyi bir test senaryosu neyi cevaplar

Test senaryosu, bir gereksinimin gerçekten karşılandığını kanıtlayan, başkası tarafından da aynı sonuçla yeniden çalıştırılabilen yazılı bir denemedir. İyi bir senaryo şu sorulara net cevap verir: hangi durumda başlıyoruz, ne yapıyoruz, ne görmeyi bekliyoruz. Bu yanıtlardan biri belirsizse test, yapana göre farklı sonuç verir ve güvenilirliğini kaybeder.

Senaryo ile test vakası arasındaki sözcük ayrımı kurumdan kuruma değişir. Bazı ekiplerde senaryo üst düzey bir durumu ("kullanıcı kayıt olabilir"), vaka ise o durumun ayrıntılı adımlarını anlatır. Ekibinizin kullandığı terimi bir kez netleştirmek, aynı kavram için farklı belgeler yazılmasını önler.

Yazmaya başlamadan önce elinizde olması gereken şeyler: gereksinim ya da kullanıcı hikâyesi, kabul kriterleri, ekran tasarımı ya da API sözleşmesi ve varsa iş kuralı belgesi. Bunlardan biri eksikse yazdığınız senaryo tahmine dayanır; önce analiste ya da ürün sahibine sorun.

Bir test senaryosunun alanları

Test yönetim aracı ne olursa olsun, her senaryoda şu alanlar bulunmalıdır:

• Kimlik ve başlık: Başlık eylemi ve sonucu söylemelidir. "Giriş testi" değil, "Hatalı parolayla girişte hata mesajı gösterilir".
• Gereksinim bağı: Hangi kabul kriterinin ya da hikâyenin sınandığı. Bu bağ olmadan kapsam hesaplanamaz.
• Ön koşul: Başlamadan önce sistemde var olması gereken durum: kayıtlı kullanıcı, doluluk durumu belirli bir sepet, belirli bir yetki.
• Test verisi: Kullanılacak girdi değerleri. Gerekirse veri kümesini senaryodan ayırıp başvuru verin.
• Adımlar: Kısa, sıralı, her biri tek eylem.
• Beklenen sonuç: Gözlenebilir ve ölçülebilir. "Sistem düzgün çalışır" bir beklenen sonuç değildir.
• Öncelik ve tür: Kritik akış mı, olumsuz durum mu, regresyon paketine girecek mi?

Beklenen sonucu adımlara gömmek yerine ayrı bir alanda tutmak, hata raporu yazarken de işinizi kolaylaştırır: gerçek sonuç ile beklenen sonuç doğrudan karşılaştırılır.

Adım adım: gereksinimden senaryoya

Şu yöntem, herhangi bir özellik için uygulanabilir.

Önce kabul kriterlerini tek tek okuyun ve her birini sınanabilir bir cümleye çevirin. Sınanamayan kriter ("hızlı olmalı") yazılmadan önce netleştirilmelidir.

Sonra girdi alanlarını çıkarın. Her alan için geçerli değerler, geçersiz değerler ve sınırlar belirlenir; bu aşamada eşdeğerlik sınıfları ve sınır değer analizi kullanılır. Her sınıftan bir temsilci seçmek, aynı davranışı onlarca kez sınamaktan çok daha verimlidir.

Ardından akışları ayırın: ana akış (her şeyin yolunda gittiği), alternatif akışlar (farklı ama geçerli yollar) ve hata akışları (reddedilen girdi, kesilen bağlantı, yetkisiz erişim). Her akış için ayrı senaryo yazın.

Sonra her senaryoyu yazın: başlık, ön koşul, adımlar, beklenen sonuç. Yazdıktan sonra başka birine verin; açıklama yapmadan çalıştırabiliyorsa senaryo yeterince açıktır.

Son olarak gereksinim ile senaryoları eşleştirin. Hiçbir senaryoya bağlanmamış kabul kriteri, kapsam boşluğudur.

Örnek: havale işlemi için senaryolar

Örneğin bir mobil bankacılık uygulamasında, kullanıcının kendi hesaplarından başka bir kişiye havale yapabildiği bir özellik düşünelim. Kabul kriteri: yeterli bakiye varsa havale gerçekleşir, bakiye yetersizse işlem reddedilir ve kullanıcıya nedeni söylenir.

Ana akış senaryosu: Başlık: Yeterli bakiyeyle havale tamamlanır. Ön koşul: Gönderen hesapta, havale tutarını karşılayacak bakiye var; alıcı hesap tanımlı. Adımlar: Havale ekranını aç, alıcıyı seç, tutarı gir, onayla. Beklenen sonuç: Gönderen bakiyesi tutar kadar azalır, alıcıya işlem kaydı düşer, kullanıcı onay ekranı görür.

Hata akışı senaryosu: Başlık: Yetersiz bakiyede havale reddedilir ve neden belirtilir. Ön koşul: Gönderen hesap bakiyesi, girilecek tutardan düşük. Beklenen sonuç: İşlem gerçekleşmez, bakiye değişmez, ekranda bakiyenin yetersiz olduğunu söyleyen mesaj görünür.

Sınır senaryosu: Tutar, bakiyeyle tam eşit olduğunda işlemin sonucu. Kuralı belgeden okuyun; belgede yoksa ürün sahibine sorun.

Bu örnekte görünen alışkanlığa dikkat edin: her senaryoda bakiye hem işlemden önce hem sonra kontrol ediliyor. Yan etkiyi (bakiye değişimi, kayıt oluşması) sınamak, ekrandaki mesajı sınamaktan daha çok hata yakalar.

Gherkin biçimi: Verilen, Olduğunda, O zaman

Birçok çevik ekip senaryoyu Gherkin dilinde yazar. Yapı sadedir: bir başlangıç durumu, bir eylem, bir sonuç.

Senaryo: Yetersiz bakiyeyle havale reddedilir Verilen ki hesabımda gönderilecek tutardan az bakiye var Olduğunda havaleyi onaylarım O zaman işlem reddedilir Ve bakiye yetersiz mesajı görünür

Gherkin'in avantajı, analist, geliştirici ve test uzmanının aynı cümleyi okuyabilmesidir. Ancak yalnızca biçim olarak kullanılırsa değer katmaz. Sık yapılan hata, senaryoya arayüz ayrıntısı doldurmaktır: "düğmeye tıkla, kutuya yaz". İyi bir Gherkin senaryosu davranışı anlatır, arayüzün nasıl sürüldüğünü adım tanımlarına bırakır. Böylece ekran tasarımı değiştiğinde senaryo da değişmek zorunda kalmaz.

Gherkin zorunlu değildir. Manuel testte tablo biçimli adım listesi, keşif testinde görev tanımı (charter) daha uygun olabilir. Önemli olan, ekibin tek bir ortak dil seçmesidir.

Yaygın hatalar ve nasıl kaçınılır

Çok adımlı, tek senaryoda çok şey sınayan testler: Başarısız olduğunda nedeninin ne olduğu anlaşılmaz. Bir senaryo tek bir davranışı sınasın.

Belirsiz beklenen sonuç: "Doğru görüntülenir", "hata vermez". Gözlenebilir bir çıktı yazın: ekranda gösterilen metin, veritabanında oluşan kayıt, dönen durum kodu.

Senaryoların birbirine bağımlı olması: Bir senaryo ancak öncekinin bıraktığı veriyle çalışıyorsa, sıra değişince ya da tek başına çalıştırınca bozulur. Her senaryo ön koşulunu kendisi kurmalıdır.

Sadece olumlu akışı yazmak: Üretimde hatalar çoğunlukla olumsuz yollarda çıkar: boş alan, çok uzun metin, geçersiz biçim, yetkisiz kullanıcı, kesilen ağ. Olumsuz akış senaryolarını bilinçli olarak planlayın.

Güncellenmeyen senaryolar: Gereksinim değiştiğinde senaryo da değişmelidir. Gereksinim bağı olan senaryolar, hangilerinin etkilendiğini bulmayı kolaylaştırır.

Kopya yapıştır çoğaltma: Aynı senaryonun farklı veri ile yinelenmesi, veri kümesi kullanılarak tek senaryoya indirilebilir; bakım yükü düşer.

Senaryo yazma becerisini nasıl geliştirirsiniz

Önce küçük bir özellikle başlayın: kayıt formu, arama kutusu, bir indirim kuralı. Kabul kriterlerini yazın, sonra senaryoları, sonra başkasına okutun. Okuyanın sorduğu her soru, senaryonun belirsiz kalan yerini gösterir.

Sonra test tasarım tekniklerini sistemli kullanın: eşdeğerlik sınıfları, sınır değer analizi, karar tablosu, durum geçişi. Bunlar tahmin yerine yöntem kazandırır. Ayrıca gerçek hata raporlarını inceleyin: üretimde kaçan her hata, hangi senaryonun eksik olduğunu gösteren bir ders niteliğindedir.

Test Otomasyonu ve QA Temelleri programında Test Senaryosu Tasarım Teknikleri modülü; eşdeğer bölümleme, sınır değer analizi, karar tablosu, durum geçiş testi ve pairwise test konularını kapsar. Programın diğer modülleri hata yönetimini ve çevik ortamda QA'yı da işler. Hem yeni başlayan test uzmanları hem de analiz ve geliştirme tarafından test yazmaya geçen çalışanlar için uygun bir temeldir.