Test Senaryosu ve Test Durumu: Temel Farklar

"Test senaryosu" ve "test durumu" aynı anlama geliyormuş gibi kullanılır. Oysa aynı değillerdir. Bunları karıştırmak, test planlarının ya uygulanamayacak kadar belirsiz ya da okunmayacak kadar detaylı olmasına yol açar. Biri neyin test edileceğini açıklarken; diğeri tam olarak nasıl test edileceğini açıklar. İlişkiyi doğru kurduğunuzda, kapsamınız hem denetlenebilir hem de çalıştırılabilir hale gelir.

Bu rehber, her terimi tanımlar, farklılıklarını yan yana sunar ve ikisinin Apidog kullanarak gerçek bir API test iş akışında nasıl birlikte çalıştığını gösterir.

Test senaryosu nedir?

Test senaryosu, test etmeye değer bir şeyin üst düzey bir ifadesidir. Tam adımları, girdileri veya beklenen değerleri belirtmeksizin bir davranışı veya koşulu adlandırır.

Bunu bir başlık gibi düşünün. Bir e-ticaret ödeme akışı için senaryolar şöyle olabilir:

• Kayıtlı bir kullanıcının kayıtlı bir kartla ödeme yapmasını doğrula
• Misafir bir kullanıcının ödeme yapmasını doğrula
• Satın alma sırasında bir ürünün stoğu tükendiğinde ödeme akışını doğrula
• Ödeme reddedildiğinde ödeme akışını doğrula

Her satır size neyi doğrulamanız gerektiğini ve bunun iş için neden önemli olduğunu söyler. Hiçbiri size hangi uç noktayı çağıracağınızı veya hangi veri yükünü (payload) göndereceğinizi söylemez. Bir senaryo, kullanıcının veya gereksinimin bakış açısından yazılır, böylece hem ürün yöneticileri hem de mühendisler tarafından okunabilir kalır.

Senaryolar tek bir soruyu yanıtlar: Çalışması gereken her şeyi düşündük mü? Onlar kapsama haritasıdır. Bir senaryo eksikse, ne kadar detaylı test durumu olursa olsun bu boşluğu kapatamaz.

Test durumu nedir?

Test durumu, bir senaryonun altında yer alan somut, çalıştırılabilir kontroldür. Tam girdiyi, ön koşulu, eylemi ve beklenen sonucu, iki kişinin çalıştırdığında aynı sonucu alacağı kadar hassasiyetle belirtir.

"Misafir kullanıcı için ödeme akışını doğrula" senaryosunu ele alalım. Bu, aşağıdaki gibi durumlara ayrılır:

• Geçerli bir misafir veri yükü (payload) ile POST /orders çağrısı 201 ve bir order_id döndürür
• Gönderim adresi olmayan POST /orders çağrısı 400 ve bir validation_error döndürür
• Stoğu tükenmiş bir SKU ile POST /orders çağrısı 409 ve error: out_of_stock döndürür

Her durum uç noktayı, gövdeyi, beklenen durumu ve beklenen yanıt alanlarını adlandırır. Otomatikleştirilebilecek kadar spesifiktir. Bir durumun alan bazında tam anatomisini merak ediyorsanız, API test durumları nasıl yazılır şablonu detaylı olarak ele alır ve test durumu ve test betiği çalıştırılabilir kodun nereye oturduğunu açıklar.

Bir test durumunun belirleyici özelliği hassasiyettir. "Ödeme çalışıyor" en iyi ihtimalle bir senaryo parçacığıdır. "Geçerli bir misafir siparişi POST et, boş olmayan bir order_id ile 201 bekle" bir test durumudur.

Temel farklılıklar

İki kavram birçok boyutta farklılık gösterir. Bu tablo kısa versiyonudur.

İlişki hiyerarşiktir. Bir senaryo birden fazla durum ortaya çıkarır. Senaryo kapsamın genişliğini kontrol eder; durumlar derinliği ve titizliği kontrol eder. Yaygın bir hata modu, üstlerinde senaryo haritası olmadan düzinelerce detaylı durum yazmaktır, bu da özelliğin tam olarak kapsanıp kapsanmadığını veya sadece bir köşede yoğun bir şekilde test edilip edilmediğini söylemeyi imkansız hale getirir.

Başka bir bakış açısıyla: bir senaryo "kapsandı" veya "kapsanmadı" olarak işaretlenebilir. Bir test durumu ise yalnızca "başarılı" veya "başarısız" olarak işaretlenebilir. Kaliteyi yönetmek için her iki duruma da ihtiyacınız var.

Senaryolar ve durumlar nasıl birlikte çalışır?

Pratik bir iş akışı, genişten özele doğru beş adımda ilerler.

1. Gereksinimlerden senaryoları belirleyin. Şartnameyi veya API dokümantasyonunu okuyun ve doğrulamanız gereken her davranışı, olumsuz akışlar dahil olmak üzere listeleyin. Eksik kapsam burada yakalanır, bu yüzden buraya gerçek zaman ayırın.

2. Her senaryonun amacını tanımlayın. "Tamamlandı"nın ne anlama geldiğini belirtin. "Misafir ödeme akışını doğrula" için amaç, bir misafirin sipariş verebilmesi ve bir onay alması, geçersiz siparişlerin ise düzgün bir şekilde reddedilmesidir.

3. Her senaryo altında test durumları yazın. Her senaryoyu girdiler ve beklenen sonuçlarla somut durumlara genişletin. Başarılı akışı (happy path), her doğrulama hatasını ve ilgili uç koşulları kapsayın.

4. Tamamlığı gözden geçirin. Ağacın tepesine geri dönün. Her senaryonun en az bir başarılı akış durumu ve bir negatif durumu var mı? Dokümantasyondaki her durum kodu beklenen bir sonuçta görünüyor mu? Burada bulunan boşluklar ucuzdur; üretimde bulunanlar değildir.

5. Yürütün ve sonuçları takip edin. Durumları çalıştırın, her durum için geçme ve kalma durumunu kaydedin ve sonuçları senaryo seviyesine taşıyın, böylece paydaşlar sadece yeşil çek işaretlerinin sayısını değil, kapsamı da görsün.

Davranış odaklı ekipler için senaryolar doğal olarak Gherkin'in Verilen-Ne Zaman-O Zaman (Given-When-Then) formatına eşleşir; BDD API testi için Gherkin rehberi bu yapının senaryoları yürütülebilir kalırken nasıl okunabilir tuttuğunu gösterir.

Çalışılmış bir örnek: senaryodan durumlara

Bir not uygulaması için bir API ele alalım, test etmeye değer tek bir davranış: bir kullanıcı not oluşturabilir. Bu senaryodur.

Senaryo: Bir kullanıcı not oluşturabilir. Tek bir satır. Test planında yer alır, herkes tarafından okunabilir. Uç noktaları, veri yüklerini veya durum kodlarını belirtmez ve belirtmemelidir.

Şimdi bunu durumlara genişletin. Her durum, tam girdiler ve tam beklenen sonuç ile bir çalıştırılabilir kontroldür.

• Durum 1, başarılı akış (happy path). {"title": "Alışveriş", "body": "süt, yumurta"} ve geçerli bir token ile POST /notes. 201 bekleyin, boş olmayan bir id, Alışveriş'e eşit bir title ve bir created_at zaman damgası içeren bir yanıt gövdesi bekleyin. Yanıt 600 ms altında olmalı.
• Durum 2, gerekli alan eksik. {"body": "süt, yumurta"} ve geçerli bir token ile POST /notes. 400 bekleyin, validation_error'a eşit bir error ve title alanını belirten details bekleyin.
• Durum 3, kimliği doğrulanmamış. Geçerli bir gövde ve tokensiz POST /notes. 401 ve yanıtta id olmamasını bekleyin.
• Durum 4, aşırı büyük veri yükü. 2 MB'lık bir body ile POST /notes. 413 ve açık bir hata mesajı bekleyin.

Bir senaryo, dört durum. Senaryo size neyi anlattı; durumlar size nasılı anlattı, herhangi bir test uzmanının veya otomatik çalıştırıcının aynı kararı vereceği kadar hassasiyetle. Daha sonra "bir kullanıcı bir nota dosya ekleyebilir" derseniz, bu yeni bir senaryo olur ve kendi durum setini ortaya çıkarır. Plan, düz bir kontrol yığını haline gelmek yerine yapılandırılmış, denetlenebilir bir şekilde büyür.

Apidog'da senaryolar ve durumlar oluşturma

Apidog bu hiyerarşiyi doğrudan modeller, böylece test planınızdaki yapı araçlarınızdaki yapıyla eşleşir.

Apidog'daki bir test senaryosu, her biri kendi doğrulama (assertion) setine sahip, sıralı API isteklerinden oluşan bir dizidir. Bunu görsel olarak oluşturursunuz: davranışa dahil olan uç noktaları ekler, bir isteğin çıktısının bir sonrakini beslemesi için bunları zincirlersiniz (bir giriş token döndürür, bir sonraki istek bunu kullanır) ve her adımda doğrulamaları ayarlarsınız.

Her istek-artı-doğrulama bloğu aslında bir test durumudur. Durum kodlarını, yanıt gövdesi alanlarını, şema uyumluluğunu ve yanıt süresini, bir betik yazmadan tıklayarak doğrulayabilirsiniz. Veriye dayalı test, tek bir durumun bir CSV veya JSON dosyasından birçok giriş satırına karşı çalışmasına olanak tanır, böylece tek bir negatif durum her geçersiz kombinasyonu kapsar.

Senaryolar daha sonra tüm bir API üzerinde düzenli, tekrarlanabilir çalıştırmalar için test süitleri halinde gruplanır. Bir süiti yerel olarak, bir zamanlamaya göre veya CI içinde çalıştırabilirsiniz ve Apidog, hem durum düzeyinde hem de senaryo düzeyinde sonuçları gösteren bir rapor üretir. Bu ikili görünümün getirisi şudur: mühendisler hangi durumun başarısız olduğunu görür ve yöneticiler hangi senaryonun risk altında olduğunu görür.

İlk senaryonuzu oluşturmak ve durumdan senaryoya geçişin uygulamada nasıl çalıştığını görmek için Apidog'u indirin.

Neden sadece birini değil, ikisini de ihtiyacınız var?

Ekipler bazen bir katmanı atlamaya çalışır. Senaryoları atlamak ve sadece durumlar yazmak, kapsama haritası olmayan uzun, düz bir liste üretir; "misafir ödeme akışını tamamen test ettik mi?" sorusunu her durumu tekrar okumadan yanıtlayamazsınız. Durumları atlamak ve sadece senaryoları tutmak, kimsenin tutarlı bir şekilde uygulayamayacağı bir plan üretir, çünkü "ödeme akışını doğrula" her test uzmanı için farklı bir anlama gelir.

İki katman aynı zamanda farklı okuyuculara hizmet eder. Bir ürün yöneticisi, doğru şeylerin test edildiğini doğrulamak için senaryoları okur. Bir otomasyon mühendisi, çalıştırıcıları oluşturmak için durumları okur. Sadece geçen durumları gösteren bir test raporu, yönetime kapsama hakkında hiçbir şey söylemez; durumları senaryolara yuvarlayan bir rapor, onlara hangi özelliklerin gönderilmesinin güvenli olduğunu tam olarak söyler.

Senaryoları stabil, durumları güncel tutun. Senaryolar ancak özelliğin amacı değiştiğinde değişir. Durumlar ise API sözleşmesi değiştiğinde değişir. Bunları ayrı yaşam döngülerine sahip ayrı yapılar olarak ele aldığınızda, test planınız hem doğru hem de sürdürülebilir kalır.

Sıkça Sorulan Sorular

Test senaryosu test süiti ile aynı mı? Hayır. Bir senaryo test edilecek bir davranışı tanımlar. Bir süit, bir çalıştırma için gruplandırılmış yürütülebilir testlerin bir koleksiyonudur. Bir süit, birçok senaryodan gelen durumları içerebilir. Bkz: test süiti ve test durumu.

Bir senaryonun kaç tane test durumu olmalı? Başarılı akışı (happy path) ve senaryonun ima ettiği her hata modunu kapsayacak kadar. Basit bir senaryo üç veya dört duruma ihtiyaç duyabilir; karmaşık bir senaryo daha fazlasına ihtiyaç duyar.

Senaryoları kim, durumları kim yazar? Senaryolar genellikle ürün ve QA ile birlikte hazırlanır, çünkü amacı kodlarlar. Durumlar ise genellikle QA veya geliştiriciler tarafından yazılır, çünkü teknik detayı kodlarlar. Test durumu spesifikasyon formatı, durum yazımının tutarlı kalmasına yardımcı olur.

Testlerim otomatize edilmişse senaryolara ihtiyacım var mı? Evet. Otomasyon durumları çalıştırır, ancak senaryolar yine de doğru durumların var olup olmadığını yanıtlar. Kapsam haritası olmayan otomasyon sadece daha hızlı başarısız olur.