Yazılım testine yeni başlayan hemen herkesin aklındaki ilk soru aynıdır: “Test senaryosu yazmam gerekiyor ama nereden başlayacağım?”
Bu sorunun cevabı aslında çok daha basit bir soruya dayanır: “Bu özelliği kullanan biri ne yapmak ister?” Eğer bunu doğru yanıtlayabiliyorsanız, zaten iyi bir test senaryosu yazabilirsiniz.
Test senaryosu yazmak; özel araçlar, karmaşık şablonlar ya da yıllarca deneyim gerektirmez. Gerektirdiği şey: kullanıcıyı anlamak, sistemi tanımak ve gözlemlemek. Bu rehberde, sıfırdan başlayan bir tester olarak test senaryosu yazmanın tüm temellerini öğreneceksiniz.
Haydi başlayalım.
1. Test Senaryosu Nedir?
Test senaryosu (test case), bir yazılım özelliğini ya da akışını doğrulamak için hazırlanan, belirli adımları, koşulları ve beklenen sonuçları içeren yapılandırılmış bir belgedir.
Daha sade bir tanımla: “Bu butona tıkladığımda ne olması gerekiyor?” sorusunu ve cevabını kağıda dökmektir.
Sık yapılan yanlış anlama şudur: test senaryosu, sadece “ne test edileceğinin listesi” değildir. Listeleme bir başlangıçtır; ancak senaryonun asıl değeri şuradan gelir:
- Testin hangi koşullarda yapılacağını netleştirir.
- Beklenen sonucu önceden belirler, böylece “geçti mi geçmedi mi” sorusunun yanıtı tartışmaya açık olmaz.
- Ekip içinde ortak bir dil oluşturur — geliştirici, tester ve ürün yöneticisi aynı sayfada buluşur.
- İlk kez gören biri tarafından bile eksiksiz uygulanabilecek kadar açık olmalıdır.
Test Senaryosu ile Test Planı Arasındaki Fark
Yeni başlayanların en çok karıştırdığı iki kavramdır. Basit ayrımla:
- Test Planı: Projenin tamamının nasıl test edileceğini anlatan üst düzey belgedir. Kapsam, kaynaklar, zaman çizelgesi ve risk analizi içerir.
- Test Senaryosu: Tek bir özelliği ya da akışı test eden somut, uygulanabilir bir birimdir.
Test planı stratejidir; test senaryosu ise o stratejinin sahadaki yansımasıdır.
2. Bir Test Senaryosunun Temel Bileşenleri
Kullandığınız araç ne olursa olsun — Excel, Notion, Jira, TestRail ya da düz bir metin belgesi — her test senaryosunda bulunması gereken altı temel bileşen vardır.
- 1. Test Senaryosu No (TC ID): Her senaryoyu benzersiz bir kodla tanımlayın. Örn: TC-001. Bu kod, bug report yazarken ya da senaryoya atıfta bulunurken büyük kolaylık sağlar.
- 2. Senaryo Adı: Ne test edildiğini tek cümlede özetleyen başlık. Kısa, net ve anlaşılır olmalı. Örn: “Kullanıcı geçersiz e-posta ile kayıt olmaya çalışıyor.”
- 3. Ön Koşul: Test başlamadan önce sağlanması gereken durum. Örn: “Kullanıcı kayıt sayfasında, henüz form doldurmamış.” Ön koşul net tanımlanmadığında aynı senaryo farklı sonuçlar verebilir.
- 4. Test Adımları: Uygulanacak işlemler, sıralı ve net biçimde. Her adım tek bir eylemi tanımlamalı. “Formu doldur” yerine “Ad alanına ‘Ahmet’ yaz” gibi spesifik olun.
- 5. Beklenen Sonuç: Adımlar doğru uygulandığında sistemin nasıl davranması gerektiği. Bu alan ne kadar net yazılırsa, testin geçip geçmediğini anlamak o kadar kolay olur. “Hata gösterilir” yazmak yeterli değil; “‘Bu alan zorunludur.’ hata mesajı görüntülenir” yazın.
- 6. Gerçekleşen Sonuç: Test sırasında sistemin gerçekte nasıl davrandığı. Hata varsa burada not düşülür. Bu alan, bug report yazımında temel kaynak olur.
İsteğe bağlı olarak Öncelik (Kritik / Yüksek / Orta / Düşük) ve Tip (Happy Path / Negatif / Edge Case) alanları da eklenebilir. Bu alanlar test sürecini önceliklendirmenizi kolaylaştırır.
3. Başlamadan Önce: Neyi Test Ettiğinizi Anlayın
Test senaryosu yazmadan önce, test edilecek özelliği gerçekten anlamak gerekir. Bu kulağa basit gelir ama pratikte en çok atlanan adımdır. Özelliği yüzeysel anlamak, yüzeysel senaryolar doğurur.
Başlamadan önce kendinize şu soruları sorun:
- Bu özellik ne işe yarıyor? Kullanıcıya ne sağlıyor?
- Kimler kullanacak? Farklı kullanıcı profilleri var mı?
- Doğru çalışması için hangi koşulların sağlanması gerekiyor?
- Kullanıcı yanlış bir şey yaparsa sistem nasıl davranmalı?
- Bu özellik başka hangi özelliklerle etkileşiyor?
- Performans, güvenlik ya da erişilebilirlik açısından özel gereksinimler var mı?
Bu soruların yanıtlarını bulmak için geliştirici ekipten, ürün dokümanlarından ya da doğrudan kullanıcı hikayelerinden (user stories) yararlanabilirsiniz. Belirsizlik varsa sormaktan çekinmeyin — açıklığa kavuşturmak, test aşamasında değil daha erken yapılmalıdır.
4. Happy Path’ten Başlayın, Sonra Genişletin
Nereden başlayacağınızı bilmiyorsanız cevap her zaman aynıdır: happy path’ten başlayın.
Happy Path Nedir?
Happy path, her şeyin doğru gittiği, kullanıcının tam olarak beklenen şekilde hareket ettiği senaryodur. Sistemi önce bu gözle test etmek, temel işlevselliği doğrulamanızı sağlar. Eğer happy path dahi çalışmıyorsa, diğer senaryolara geçmenin anlamı yoktur.
Sonra Genişletin: Negatif ve Edge Case Senaryolar
Happy path çalışıyorsa, sıra sistemi zorlamaya gelir. Şu sorular sizi doğal olarak diğer senaryolara götürür:
- Negatif senaryolar: Kullanıcı yanlış bir şey girerse ne olur? Zorunlu alan boş bırakılırsa? Geçersiz format kullanılırsa?
- Edge case’ler: Aynı işlem iki kez yapılırsa? Çok uzun bir metin girilirse? Minimum ve maksimum değerlerde sistem nasıl davranır?
- İzin senaryoları: Yetkisi olmayan bir kullanıcı bu özelliğe erişmeye çalışırsa ne olur?
- Bağımlılık senaryoları: Bu özellik başka bir özelliğin çıktısına mı bağlı? O özellik hatalı veri üretirse ne olur?
Asıl hatalar çoğu zaman happy path’te değil, bu ara senaryolarda saklıdır. Geliştirici ekipler genellikle doğru kullanım üzerine odaklandığından, yanlış kullanım durumları gözden kaçabilir.
5. Test Senaryosu Yazarken Yapılan Yaygın Hatalar
Yeni başlayan testerlerin düştüğü belirli hatalar vardır. Bu hataları önceden bilmek, aynı tuzaklara düşmenizi önler.
- Adımları çok genel yazmak: “Formu doldur” yerine “Ad alanına ‘Ahmet Yılmaz’ yaz” gibi spesifik olun. Genel adımlar, farklı kişilerin farklı şeyler yapmasına yol açar ve tutarsız sonuçlar doğurur.
- Beklenen sonucu belirsiz bırakmak: “Hata mesajı gösterilir” yazmak yeterli değil. Hangi hata mesajı? Nerede? Hangi renkle? Ne kadar süre görünür? Beklenen sonuç, testin geçip geçmediğini belirleyen kriterdir.
- Ön koşulu atlamak: Ön koşulsuz yazılan senaryolar, farklı ortamlarda farklı sonuçlar verebilir. “Kullanıcı giriş yapmış” mı, “misafir” mi? Bu fark büyük önem taşır.
- Sadece happy path yazmak: Sistemi yalnızca doğru kullanım üzerinden test etmek, gerçek kullanıcı davranışlarının yalnızca küçük bir kısmını kapsar. Negatif senaryoları atlamak kritik hataların gözden kaçmasına neden olur.
- Çok fazla senaryo yazmaya çalışmak: Amaç, her olası durumu kapsamak değildir. Amaç, anlamlı ve farklı senaryoları kapsamaktır. Birbirine çok benzeyen onlarca senaryo, bakımı zor bir belge yığınından başka bir şey değildir.
- Senaryoları güncellememeek: Özellik değişti ama senaryo değişmedi. Bu durum, geçmiş bir testin geçti olarak işaretlenmesine yol açabilir — oysa test artık doğru özelliği ölçmüyordur.
6. Kaç Senaryo Yeterlidir?
“Ne kadar çok senaryo, o kadar iyi test” mantığı yanlıştır. Amaç kapsam genişliği değil, kapsam kalitesidir.
Bir senaryonun belgeye alınmaya değer olup olmadığını anlamak için şu testi uygulayın: “Bu senaryo olmasa neyi kaçırırdım?” Eğer yanıt net değilse, o senaryo muhtemelen zaten başka bir senaryonun içinde kapsanıyordur.
Pratik bir yaklaşım olarak, önce kritik öneme sahip özellikler ve kullanıcıların en çok kullandığı akışlar için senaryo yazın. Zamanla kapsam genişletilir.
Kalitenin miktarı yendiği tek alan değildir — test senaryolarında da aynı kural geçerlidir.
7. Test Senaryolarını Canlı Tutun
Test senaryoları, bir kez yazılıp rafa kaldırılan belgeler değildir. Yazılım geliştikçe, özellikler değiştikçe senaryoların da güncellenmesi gerekir.
Güncellenmemiş bir test senaryosu, yanlış güven verir. “Bu test geçti” demek, eski senaryoya göre geçti anlamına gelebilir — oysa özellik çoktan değişmiş olabilir.
Senaryolarınızı güncel tutmak için basit ama etkili alışkanlıklar:
- Her yeni özellik geliştirmesinde, ilgili senaryoları gözden geçirin.
- Her bug fix sonrası, o hatayı kapsayan bir senaryo ekleyin — aynı hata tekrarlanmasın diye.
- Sprint döngülerinizde senaryo güncellemesini bir kabul kriteri olarak tanımlayın.
- Eski ve geçerliliğini yitirmiş senaryoları arşivleyin, silmeyin — ileride referans olarak işe yarayabilir.
8. Hangi Araçları Kullanmalısınız?
Test senaryosu yazmak için mutlaka özel bir araca ihtiyacınız yok. Başlangıçta en önemli olan araç değil, yapıdır.
- Excel / Google Sheets: Hızlı başlangıç için idealdir. Senaryo no, adım, beklenen sonuç sütunlarını kendiniz oluşturabilirsiniz. Ekiple paylaşım kolaylığı sağlar.
- Notion / Confluence: Dokümantasyonla entegre çalışmak isteyenler için uygun. Özellikle ürün dokümanlarıyla birlikte tutmak avantajlı.
- Jira + Zephyr / Xray: Geliştirme süreçleriyle entegre çalışan ekipler için güçlü seçenekler. Bug’larla doğrudan ilişkilendirme imkânı sunar.
- TestRail: Test yönetimine özel geliştirilmiş bir platform. Büyük ekipler ve karmaşık projeler için uygundur.
Yeni başlayan biri için tavsiye: Excel ya da Google Sheets ile başlayın. Yapıyı öğrendikçe daha gelişmiş araçlara geçmek çok daha kolay olacaktır.
9. Örnek: Basit Bir Login Senaryosu
Teoriyi pratiğe dökmek için basit bir örnek üzerinden gidelim. Bir web uygulamasının login sayfasını test ediyorsunuz.
TC-001 — Geçerli bilgilerle başarılı giriş (Happy Path)
- Ön Koşul: Kullanıcı sisteme kayıtlı. Login sayfası açık.
- Adımlar: (1) E-posta alanına geçerli bir e-posta gir. (2) Şifre alanına doğru şifreyi gir. (3) “Giriş Yap” butonuna tıkla.
- Beklenen Sonuç: Kullanıcı dashboard sayfasına yönlendirilir. Üst menüde kullanıcı adı görüntülenir.
TC-002 — Yanlış şifreyle giriş denemesi (Negatif)
- Ön Koşul: Kullanıcı sisteme kayıtlı. Login sayfası açık.
- Adımlar: (1) E-posta alanına geçerli e-posta gir. (2) Şifre alanına yanlış bir şifre gir. (3) “Giriş Yap” butonuna tıkla.
- Beklenen Sonuç: Giriş gerçekleşmez. “E-posta veya şifre hatalı.” mesajı gösterilir. Şifre alanı temizlenir.
TC-003 — Şifre alanı boş bırakarak giriş denemesi (Negatif)
- Ön Koşul: Login sayfası açık.
- Adımlar: (1) E-posta alanına geçerli e-posta gir. (2) Şifre alanını boş bırak. (3) “Giriş Yap” butonuna tıkla.
- Beklenen Sonuç: Form gönderilmez. Şifre alanı altında “Bu alan zorunludur.” uyarısı gösterilir.
Sadece üç senaryo, ama doğru yapılandırıldığında login özelliğinin kritik noktalarını kapsıyor. Bunlara ek olarak “5 başarısız deneme sonrası hesap kilitlenmesi” veya “Şifremi unuttum akışı” gibi senaryolar da yazılabilir.
Özet: Yeni Başlayan Tester İçin 7 Altın Kural
- Önce özelliği anlayın, sonra yazmaya başlayın.
- Her zaman happy path’ten başlayın.
- Adımları spesifik yazın — genel ifadelerden kaçının.
- Beklenen sonucu tartışmaya yer bırakmayacak kadar net tanımlayın.
- Negatif senaryoları atlamayın — hatalar çoğunlukla orada saklanır.
- Senaryolarınızı güncel tutun — eski senaryo, yanlış güven verir.
- Araçtan önce yapıyı öğrenin — Excel bile yeterlidir.
Test senaryosu yazmak bir yetenek değil, bir alışkanlıktır. Ne kadar çok yazarsanız, o kadar hızlı ve güvenilir hale gelirsiniz.
Ve eğer bu süreci dışarıdan, bağımsız bir gözle yürütmek istiyorsanız — Vidius Project tam da bunun için burada.