Çoğu test senaryosu, tek bir hata bile yakalayamadan başarısız olur. Bu senaryolar belirsiz kontrol listeleri şeklinde yazılır, ön koşullar eksik bırakılır, birden fazla eylem tek bir adımda birleştirilir veya beklenen sonuçlar o kadar muğlak bir şekilde tanımlanır ki, aynı senaryoyu okuyan iki test uzmanı “başarılı” ifadesinin ne anlama geldiği konusunda anlaşamaz. Sonuç olarak hatalar gözden kaçar, test çalıştırmaları tekrarlanamaz ve kalite güvencesi (QA), bir güvenlik ağı yerine bir darboğaz haline gelir.
İyi bir test senaryosu yazmak, test becerisinden çok doğrulama tasarımıyla ilgilidir. Finans hizmetleri sektöründe buna "yapıcı-kontrolcü süreci" denir. Nükleer komut sistemlerinde ise "iki kişi kuralı" olarak adlandırılır. İlke aynıdır: Kritik işler asla tek bir kontrolsüz eyleme dayandırılmamalıdır. İyi yazılmış bir test senaryosu, yazılımda da aynı titizliği sağlar. Beklediklerinizi gözlemlediklerinizden ayırır, böylece ikisi arasındaki farkın göz ardı edilmesi imkansız hale gelir.
Size test senaryolarının nasıl yazılacağını, neden önemli olduklarını ve zaman içinde test senaryolarının kalitesini nasıl artırabileceğinizi göstereceğiz.
Özet
Bir test senaryosu, bir özelliğin doğru çalıştığını doğrulamak için gereken kesin adımları, girdileri ve beklenen sonuçları tanımlar. Her bir test senaryosunun, sonucun kontrol edilebilmesi için benzersiz bir ID'ye, ön koşullara ve beklenen sonuçlara sahip olması gerekir. Bu kılavuz, yedi adımlı yazma sürecini, üç uygulamalı örneği ve ürün değiştikçe test paketinin güvenilirliğini nasıl koruyacağınızı ele almaktadır.
Test Senaryoları Nedir?
Test senaryosu, belirli bir yazılımın doğru şekilde çalışıp çalışmadığını doğrulamak için gereken kesin adımları, girdileri, ön koşulları ve beklenen sonuçları tanımlayan yapılandırılmış bir belgedir. Test planı (test stratejisini ana hatlarıyla belirten belge) veya test komut dosyası (adımları programlı olarak yürüten otomatik kod) değildir. Test senaryosu, bu ikisinin de temelini oluşturan şartnamedir.
Örnek: Bir web uygulamasının oturum açma fonksiyonunu test ediyorsunuz. Bu özellik için bir test senaryosu aşağıdaki unsurları tanımlayacaktır:
- Kullanıcının gerçekleştirdiği adımları ve beklenen sistem yanıtlarını açıklayan eylemler
- Sistemin her adımı için yerine getirilmesi gereken kuralları tanımlayan koşullar
- Farklı sonuçları test etmek ve hem başarı hem de başarısız senaryoları doğrulamak için örnek değerlerle veri girin
Manuel ve Otomasyonlu Test Senaryolarının Karşılaştırması
AI artık çoğu test akışının bir parçasıdır. PractiTest’in 2026 Test Durumu Raporu’na göre, test uzmanlarının %76,8’i kalite güvencesinde AI kullanmaktadır; test senaryosu oluşturma (%69,6) ve komut dosyası bakımı (%59,6) en yaygın iki kullanım alanıdır. Bu değişim en çok otomatik test senaryolarında görülmektedir; bu nedenle bunların manuel test senaryolarından nasıl farklı olduğunu bilmek önemlidir.
| Parametre | Manuel test senaryoları | Otomasyonlu test senaryoları |
|---|---|---|
| Yürütme | Belgelenmiş bir dizi adımı izleyen bir insan test uzmanı tarafından gerçekleştirilir | Yazılım araçları, komut dosyaları veya yapay zeka ajanları tarafından yürütülür |
| Hız | Yavaş ve zaman alıcıdır, çünkü insanlar verileri manuel olarak girmeli ve sonuçları doğrulamalıdır | Yüzlerce test senaryosunu aynı anda çalıştırabilir |
| Tekrarlanabilirlik | İnsan hatasına ve adımların tutarsız yorumlanmasına yatkındır | Test senaryoları iyi bir şekilde yönetildiğinde, yüksek düzeyde tekrarlanabilirlik ve tutarlılık sağlanır |
| CI/CD entegrasyonu | İnsan kaynaklı darboğazlar nedeniyle hızlı ilerleyen teslimat süreçlerine entegrasyonları zordur | Her derlemede testleri çalıştırmak için CI/CD boru hatlarına doğrudan entegrasyon gerçekleştirir |
| Bakım | Gereksinimler her değiştiğinde belgelerin manuel olarak güncellenmesi gerekir | Kullanıcı arayüzü veya mantık değiştiğinde komut dosyalarını güncellemek için teknik bakım gerektirir |
| Şunlar için idealdir: | Keşifsel testler | Tekrarlanan ve regresyon testleri |
İyi Yazılmış Test Senaryolarının Önemi
Kullanıcılar sorun bildirimi göndermeden önce regresyon hatalarını yakalayın. Her kod değişikliği, halihazırda çalışan bir şeyin bozulma riskini beraberinde getirir. İyi yazılmış bir test senaryosu, her dağıtımdan sonra çalışan kalıcı bir kontrol noktası haline gelir. Bir yıl sonra bir geliştirici giriş kodunuzu yeniden düzenlerken yanlışlıkla oturum yönetimini bozarsa, bu test senaryosu bunu staging ortamında tespit eder.
Başarılı/başarısız sonuçlarını bir görüş değil, bir gerçek haline getirin. “Sistem uygun şekilde yanıt verir” gibi belirsiz beklenen sonuçlar, her test uzmanını “uygun” kelimesinin ne anlama geldiğini yorumlamaya zorlar. İki test uzmanı aynı senaryoyu çalıştırır; biri başarılı olarak işaretler, diğeri ise bir hata bildirir ve artık takım, yazılımı hata ayıklamak yerine bu anlaşmazlığı çözmeye çalışır. Beklenen sonuç “sistem ‘Geçersiz şifre’ hata mesajını görüntüler ve kullanıcıyı giriş sayfasında tutar” şeklinde yazıldığında, yoruma yer kalmaz. Sonuç ya eşleşir ya da eşleşmez. İşte pratikteki iki kişi kuralı budur: test senaryosu belirleyicidir, test uzmanı ise denetleyicidir ve ikisi de aynı dili konuşmalıdır.
Gizli bilgiyi yeniden kullanılabilir bir varlığa dönüştürürsünüz. Çoğu takımda, kıdemli QA mühendisi her sınır durumu, her geçici çözüm ve her “ah, X’i de kontrol etmeyi unutma” gibi bilgilerin görünmez bir haritasını taşır. Bu kişi izinli olduğunda veya takım değiştirdiğinde, harita da onunla birlikte gider. Açık ön koşullar ve sınır değerleri içeren belgelenmiş test senaryoları, bu bilgiyi yapısal olarak korur. Ekibe yeni katılan bir test uzmanı, TC_LOGIN_005'i seçip ilk günden itibaren “beş denemeden sonra hesap kilitlenmesi” akışını test edebilir; eşiğin ne olduğunu veya zamanlayıcının nasıl sıfırlandığını kimseye sormasına gerek kalmaz.
Hataları genel alanlara değil, kesin adımlara indirgiyorsunuz. Bir test senaryosu “sayfaya git, kimlik bilgilerini gir ve gönder’i tıkla” işlemlerini tek bir adımda birleştirdiğinde ve test başarısız olduğunda, tek bildiğiniz şey “giriş akışında bir şey bozuldu” olur. ” Her eylem, kendi beklenen sonucuna sahip ayrı bir adım olduğunda, hata 4. adımda tespit edilir: “'Sıfırlama Bağlantısını Gönder'i tıkla → beklenen başarı mesajı, 500 hatası alındı. ” Bu kesinlik, hata ayıklama süresini önemli ölçüde kısaltır; çünkü geliştirici, sadece hangi özellik alanında arama yapması gerektiğini değil, hangi etkileşimin hatayı tetiklediğini tam olarak bilir.
Nelerin kapsandığını ve nelerin kör nokta olduğunu görebilirsiniz. Yapılandırılmış test senaryoları olmadan test kapsamı bir tahminden ibarettir. Bunlar sayesinde her senaryoyu bir gereksinime eşleştirebilir ve eksiklikleri anında tespit edebilirsiniz. Şifre sıfırlama özelliğinizin altı senaryosu varsa (başarılı sıfırlama, süresi dolmuş bağlantı, yeniden kullanılan bağlantı, kayıtlı olmayan e-posta, geçersiz biçim, çoklu istek) ve bunlardan sadece üçü için test senaryolarınız varsa, bu boşluk görünür ve ölçülebilir hale gelir. Bu görünürlük, test sürecini “test ettik” durumundan “işte tam olarak neyi test ettik, neyi test etmedik ve kabul ettiğimiz risk budur” durumuna dönüştürür.
İyi Bir Test Senaryosunun Bileşenleri
Yararlı bir test senaryosu, sadece neyin test edileceğini açıklamakla kalmaz. Başka bir test uzmanı, geliştirici veya ürün yöneticisinin testi tekrarlayıp sonucu doğrulayabilmesi için bağlamı, yürütme adımlarını ve beklenen sistem davranışını da içerir.
Bir test senaryosunun bileşenleri şunlardır:
- Benzersiz tanımlayıcı
- Amaç veya açıklama
- Ön koşullar
- Yürütme adımları
- Beklenen sonuçlar
- Karşılaştırma için gerçek sonuçlar
Yukarıda paylaştığımız web sitesi giriş fonksiyonu örneği için test senaryonuz şunları içermelidir:
Test senaryosu ID: Her test senaryosunun benzersiz bir ID'si olmalıdır. Bir özelliği test ederken, kalite güvence takımları genellikle benzer koşulları doğrulayan birden fazla test senaryosu oluşturur. Test senaryosu ID, hata ayıklama veya raporlama sırasında bunları kolayca izlemenize, düzenlemenize ve referans göstermenize yardımcı olur.
Örnek: TC_LOGIN_001
Açıklama: Bu bölüm, test senaryosunun hangi fonksiyonu doğruladığını açıklar. Test senaryosunu okuyan herkesin amacını hemen anlayabilmesi için kısa bir özet sunar.
Örnek: Kayıtlı bir kullanıcının geçerli kimlik bilgilerini kullanarak uygulamaya başarıyla giriş yapabildiğini doğrulayın.
Önkoşullar: Önkoşullar, test senaryosunun yürütülmesinden önce gerekli olan sistem durumunu tanımlar. Önkoşullar olmadan, test uzmanları aynı testi farklı koşullar altında çalıştırabilir ve tutarsız sonuçlar elde edebilir.
Örnekler:
- Kullanıcı hesabı sistemde önceden mevcut olmalıdır
- Kullanıcı hesabı aktif olmalı ve kilitli olmamalıdır
- Giriş sayfasına erişilebilmelidir
Adımlar: Bunlar, bir kullanıcı veya test uzmanının test senaryosunu yürütmek için gerçekleştirdiği eylemlerdir. Takımdaki herkesin testi tekrarlayabilmesi için her adım açık ve sıralı olmalıdır.
- Kullanıcı giriş sayfasına yönlendirilir
- Kullanıcı, kayıtlı bir e-posta adresi girer
- Kullanıcı doğru şifreyi girer
- Kullanıcı Giriş düğmesine tıklar
Beklenen sonuçlar: Bu, özelliğin doğru çalıştığı durumda sistemin ne yapması gerektiğini tanımlar.
- Kimlik bilgileri geçerliyse, sistem kullanıcıyı kimlik doğrulama sürecinde doğrular
- Kullanıcı gösterge paneline yönlendirilir
- Bir kullanıcı oturumu başarıyla oluşturuldu
Kimlik bilgileri geçersizse, sistem uygun hata mesajını göstermelidir.
Gerçek sonuçlar: Bunlar, test senaryosunun çalıştırılmasından sonra test uzmanının gözlemlerini yansıtır. Gözlemlenen davranış beklenen sonuçtan farklıysa, sorun bir hata olarak kaydedilir.
Örnek gözlem:
- Geçerli kimlik bilgilerini girdim ancak “Geçersiz şifre” hata mesajı aldım
Şimdi test senaryosu yazma becerilerinizi hayata geçirelim.
Biliyor muydunuz? Takımların yalnızca %2,1'i yapay zeka test uygulamalarını optimize edilmiş olarak nitelendirirken, %85'inden fazlası hâlâ başlangıç veya deneme aşamasındadır. En yaygın kullanım alanı, risk belirleme (%19,9) gibi stratejik işler değil, test senaryoları oluşturmaktır (%69,6).
Test Senaryoları Nasıl Yazılır (Adım Adım Süreç)
Bir test senaryosu yazmak yedi adımdan oluşur: gereksinimi analiz edin, senaryoları listeye alın, yapıyı planlayın, beklenen sonuçlarla birlikte adımları yazın, ek dosya ekleyin, inceletin, ardından çalıştırın ve kaydedin.
1. Adım: Gereksinimleri analiz edin
Test senaryosunu yazmadan önce, özelliğin ne yapması gerektiğini anlayın. Bu aşamada, mevcut belgeleri (PRD'ler [ürün gereksinim belgeleri], kullanıcı hikayeleri, özellik spesifikasyonları ve tasarım belgeleri) gözden geçirerek doğrulanması gereken her bir fonksiyonu belirleyin.
Örnek: Kullanıcıların e-posta yoluyla şifrelerini sıfırlamasına olanak tanıyan bir özellik geliştiriyorsunuz. Bununla ilgili bir test senaryosu oluşturmak için şunları anlamanız gerekir:
- Bu özellik hangi sorunu çözüyor, yani bir kullanıcı şifresini unutursa hesabına yeniden erişebilir mi?
- Kullanıcı hangi işlemleri gerçekleştirebilir, örneğin sıfırlama bağlantısı isteyebilir, bunu e-posta yoluyla alabilir ve yeni bir şifre belirleyebilir mi?
- Bu işlemler gerçekleştirildiğinde ne olması gerekir, yani sistem bir sıfırlama bağlantısı gönderir ve kullanıcının şifresini başarıyla güncellemesine izin verir mi?
- Herhangi bir kısıtlama var mı, yani bağlantı belirli bir süre sonra geçerliliğini yitiriyor mu veya tek kullanımdan sonra geçersiz hale geliyor mu?
- Herhangi bir doğrulama veya kural var mı, yani yeni şifrenin belirli bir biçim veya uzunluk gereksinimlerini karşılaması gerekiyor mu?
- Herhangi bir fonksiyon belirsiz veya tanımlanmamış mı? Öyleyse, ilgili paydaşlardan netlik sağlayın.
Bu netlik, test senaryonuz için tek ve net bir hedef belirlemenize temel oluşturur.
Hedef: Kayıtlı bir kullanıcının e-posta yoluyla şifresini başarıyla sıfırlayabildiğini doğrulayın.
2. Adım: Farklı test senaryolarını belirleyin
Ardından, doğrulamanız gereken test senaryolarını listeye alın. Test senaryosu, genellikle farklı girdileri ve sonuçları kapsayan birden fazla test senaryosuna dalan üst düzey bir durumdur.
Şifre sıfırlama özelliği için senaryolarınız şöyle olabilir:
- Başarılı sıfırlama: Kayıtlı bir kullanıcının sıfırlama bağlantısı talep edebileceğini ve yeni bir şifre ayarlayabileceğini doğrulayın
- Kayıtlı olmayan e-posta: Sistemde bulunmayan bir e-posta adresi girildiğinde ne olacağını test edin
- Süresi dolmuş bağlantı: Süresi dolduktan sonra sıfırlama bağlantısına tıklandığında sistemin erişimi blokladığını doğrulayın
- Yeniden kullanılan bağlantı: Daha önce kullanılmış bir sıfırlama bağlantısının tekrar kullanılamadığını test edin
- Geçersiz yeni şifre: Biçim gereksinimlerini karşılamayan şifrelerin reddedildiğinden emin olun
- Birden fazla sıfırlama isteği: Bir kullanıcı arka arkaya birkaç sıfırlama isteğinde bulunduğunda hangi bağlantının geçerli kaldığını test edin
Buradaki her senaryo, belirli girdileri ve koşulları kapsayan bir veya daha fazla test senaryosuna dönüştürülecektir. Özelliği bu şekilde parçalara ayırmak, hem beklenen davranış hem de gerçek kullanıcıların kaçınılmaz olarak karşılaşacağı sınır durumları üzerinde test kapsamı elde etmenizi sağlar.
Daha Fazla Bilgi: QA Kontrol Listesi Nasıl Oluşturulur ve Uygulanır?
3. Adım: Testi planlayın ve test senaryosu yapısını belirleyin
Tekrarlayan regresyon testleri için, test senaryonuzu ve sonuçlarını tutarlı bir şekilde belgelemenizi sağlayan bir yapıya ihtiyacınız vardır. İyi tanımlanmış bir test senaryosu şablonu bu tutarlılığı sağlar ve her seferinde sıfırdan başlamanıza gerek kalmadan yeniden kullanım imkanı sunar.
Aşağıdaki unsurları netleştirerek test yürütmenizi planlayın:
Testi kim gerçekleştirecek?
Bu testi yürüten kişinin sahip olması gereken rol veya nitelikler nelerdir? Testin karmaşıklığına ve gerekli insan müdahalesine bağlı olarak rolleri atayın:
- Kalite Güvencesi Test Uzmanı: Oturum açma akışlarını, form doğrulamalarını veya ödeme süreçlerini kontrol etmek gibi işlevsel ve regresyon testleri
- Güvenlik takımı: Kimlik doğrulama, erişim kontrolü veya veri ifşası güvenlik açıklarını içeren testler
- Geliştirici: Şifre karma işlemi veya belirteç oluşturma gibi tek tek fonksiyonlar için birim testleri
Test nasıl gerçekleştirilecek?
- Test hangi cihazlarda ve işletim sistemlerinde çalıştırılacak?
- Hangi araçlar veya test çerçeveleri kullanılacak?
- Test manuel olarak mı yoksa bir yapay zeka ajanı aracılığıyla mı yürütülecek?
- Sonuçlar nasıl kaydedilecek: bir test yönetim aracında mı, elektronik tabloda mı yoksa hata izleme sisteminde mi?
Ön koşullar nelerdir?
1. adımdan önce gerçekleşmesi gereken tüm koşulları listeye alın ve her birinin test uzmanı tarafından kontrol edilebilir olmasını sağlayın:
Örnek:
- "test@example.com" e-posta adresine sahip bir kullanıcı hesabı mevcuttur.
- Kullanıcının sistemden oturumu kapatıldı
- E-posta hizmeti aktif ve mesajları iletebiliyor
- Test ortamına erişilebilir ve çalışır durumda
Hangi test verileri kullanılacak?
Testi çalıştırmak için gereken kesin girdi değerlerini tanımlayın: geçerli veriler, geçersiz veriler ve sınır değerleri.
Örnek:
- Geçerli: kayıtlı e-posta adresi “test@example.com”, biçim gereksinimlerini karşılayan şifre
- Geçersiz: kayıtlı olmayan e-posta adresi, şifre karakter sayısı minimum sınırın altında
- Sınır: Şifre, tam olarak minimum ve maksimum karakter sınırında olmalıdır
4. Adım: Test adımlarını ve beklenen sonuçları yazın
Yürütme sürecini sıralı adımlara ayırın. Tutarlı bir terminoloji kullanın ve her adımın tek bir eylemden oluşmasını sağlayın. Adımları tanımlarken, beklenen sonucu ve neyin başarılı ya da başarısız sayılacağını da belirtin.
Şifre sıfırlama akışımıza devam edersek, test adımları şu şekilde olacaktır:
| Adımlar | Beklenen sonuç |
| Giriş sayfasına gidin | Giriş sayfası, tıklanabilir bir “Şifremi Unuttum” bağlantısıyla yüklenir |
| “Şifremi Unuttum” seçeneğine tıklayın | Kullanıcı, şifre sıfırlama isteği sayfasına yönlendirilir |
| E-posta alanına e-posta adresinizi girin | E-posta, doğrulama hatası olmadan kabul edildi |
| “Sıfırlama Bağlantısını Gönder”i tıklayın | Başarı mesajı görüntülenir: “test@example.com adresine sıfırlama bağlantısı gönderildi” |
| E-postadaki sıfırlama bağlantısını açın | Kullanıcı, yeni şifre oluşturma sayfasına yönlendirilir |
| Geçerli bir yeni şifre girin | Şifre alanı, hata vermeden giriş kabul ediyor |
| “Şifreyi Sıfırla”yı tıklayın | Başarı mesajı görüntülenir ve kullanıcı giriş sayfasına yönlendirilir |
Şimdi, daha önce ele alınan alternatif senaryolar için adımları ve beklenen sonuçları tanımlayın. Kullanıcı geçersiz bir e-posta adresi girdiğinde veya şifre önceden belirlenmiş kriterlere uymadığında ne olacağını belirtin.
Bonus: İşte tüm test senaryolarınız için yapay zeka kullanarak dokümantasyonun otomasyonunu nasıl gerçekleştirebileceğiniz.
5. Adım: İlgili ek dosyaları ekleyin
Test uzmanlarının test senaryosunu tam bağlam içinde ve herhangi bir belirsizlik olmadan yürütmelerine yardımcı olacak ilgili belgeleri veya ek dosyaları ekleyin. Bunlar arasında şunlar yer alabilir:
- Önemli adımlarda kullanıcı arayüzünün açıklamalı ekran görüntüleri
- Farklı senaryolarda testin nasıl yürütüleceğini ve hangi sonuçların bekleneceğini gösteren ekran kayıtları
- Sistem günlükleri veya yapılandırma dosyaları, bir test başarısız olduğunda arka uç sorunlarının teşhis edilmesine yardımcı olur
- Test senaryosunu, doğruladığı kullanıcı hikayesi veya kabul kriterleriyle eşleştiren gereksinim belgeleri
- Geçerli ve geçersiz girdiler içeren test veri dosyaları veya kredi kartı sayıları, rastgele adresler ya da kullanıcı kimlik bilgileri gibi oluşturulmuş veriler
- Belirli yazılım sürümünü, gerekli donanımı, işletim sistemini ve gerekli güvenlik izinlerini kapsayan belgeleri hazırlayın
- API testleri için, istek yöntemlerini, parametreleri ve beklenen durum kodlarını ayrıntılı olarak açıklayan OpenAPI spesifikasyonları veya uç nokta belgeleri
6. Adım: Test senaryosunu incelettirin
Yazılan test senaryosunu, çalıştırmadan önce bir iş arkadaşınızla veya kıdemli bir QA lideriyle paylaşın. İnceleme sırasında şunları kontrol edin:
- Test senaryosu kapsamlıdır ve gereksinimlerden türetilen tüm olası senaryoları kapsar
- Adımlar açıktır ve gerçek yürütme akışını sırayla gösterir
- Her beklenen sonuç, "doğru çalışıyor" gibi bir nitelik değil, gözlemlenebilir bir çıktıya (bir mesaj, bir yönlendirme, bir durum kodu) atıfta bulunur.
- Test verileri ve ön koşullar tamamlandı ve doğrudur
- Yazım sırasında yapılan tüm varsayımlar açıkça belgelenir
7. Adım: Testleri çalıştırın ve sonuçları kaydedin
Testi gerçekleştirin ve her bir beklenen sonuca karşılık gelen gerçek sonucu kaydedin. Her adımda testi "başarılı" veya "başarısız" olarak işaretleyin. Başarısız olan her adım için derhal bir hata bildirimi oluşturun ve bunu test senaryosuna bağlayın. Ayrıca, açıkça "başarılı" veya "başarısız" olarak değerlendirilemeyen beklenmedik bir davranış ortaya çıkarsa, daha ayrıntılı inceleme için bunu yorum alanına not edin.
Daha Fazla Bilgi: Kalite Güvencesi için Yapay Zeka Nasıl Kullanılır?
Test Senaryosu Yazma Örnekleri
Bu üç örnek, aynı test senaryosu yapısının farklı yazılım testi türlerine nasıl uyarlanabileceğini göstermektedir. Her biri bu kılavuzun önceki bölümlerinde anlatılan bileşenleri ve adım biçimini kullanır, ancak doğruladığınız şeye bağlı olarak karmaşıklık, test verileri ve hata modları değişiklik gösterir.
Örnek 1: E-ticaret ödeme akışı (kullanıcı arayüzü, çok adımlı ş Akışı)
Bir çevrimiçi perakendecinin kalite güvence takımı, tatil indirimi öncesinde ödeme sürecini test ediyor. Akış, alışveriş sepeti → kargo → ödeme → onay olmak üzere birden fazla sayfayı kapsıyor. Buradaki en belirgin zorluk, durum bağımlılığıdır: her adım, bir önceki adımın doğru şekilde tamamlanmasına bağlıdır ve test verileri (alışveriş sepeti içeriği, teslimat adresi, ödeme yöntemi) tüm adımlar boyunca korunmalıdır.
Test Uzmanı: Rahul D.
Test tarihi: 09/03/2026
Test senaryosu ID: TC_CHECKOUT_003
Açıklama: Oturum açmış bir kullanıcının, kaydedilmiş bir kredi kartı ve standart kargo seçeneğini kullanarak satın alma işleminin tamamlandığını doğrulayın.
Ön koşullar:
- Kullanıcı hesabında en az bir kayıtlı kredi kartı ve bir kayıtlı teslimat adresi bulunmalıdır
- En az bir öğe stokta mevcut ve sepete eklendi
- Test ortamı Chrome 128 ve macOS üzerinde çalışmaktadır.
| Adım | Beklenen sonuç | Gerçek sonuç | Başarılı/Başarısız |
| Sepet sayfasına gidin | Sepet, doğru öğeyi, miktarı ve ara toplamı gösterir | Beklendiği gibi | Geç |
| "Ödemeye Devam Et"i tıklayın | Sayfa, kaydedilmiş adres önceden seçili olarak yüklenir | Beklendiği gibi | Geç |
| "Standart Kargo" seçimini yapın ve Devam'a tıklayın | Ödeme sayfası, kargo ücreti eklenmiş sipariş toplamını göstererek yüklenir | Beklendiği gibi | Geç |
| Kaydedilen kredi kartı bilgilerini onaylayın ve "Sipariş Ver" düğmesine tıklayın | Sipariş onayı sayfasında sipariş numarası, öğe özeti ve tahmini teslim tarihi görüntülenir | Ödeme sayfası şu hatayla yeniden yükleniyor: “Ödeme işlenemiyor” | Başarısız |
Sonuç özeti: Ödeme akışı, sepetten kargoya geçişi doğru şekilde işliyor, ancak kaydedilmiş kredi kartlarında ödeme işlemi başarısız oluyor. Kaydedilen hata: Ödeme ağ geçidinin yanıt vermesi 3 saniyeden uzun sürdüğünde, tokenleştirilmiş kart araması zaman aşımına uğruyor.
Örnek 2: REST API uç noktası (kullanıcı arayüzü yok, girdi/çıktı doğrulaması)
Bir arka uç mühendisi, “Kullanıcı Oluştur” API uç noktasını, ön uç takımı tarafından kullanılmaya başlanmadan önce test ediyor. Tıklanacak bir arayüz yok: test senaryosu, istek yüklerini, yanıt kodlarını ve veri kalıcılığını doğrudan doğrular. Buradaki belirleyici zorluk, kullanıcı deneyimini değil, sistemler arasındaki sözleşmeyi test etmektir.
Test Uzmanı: Sarah S.
Test tarihi: 09/05/2026
Test senaryosu ID: TC_API_USER_001
Açıklama: /api/v1/users adresine gönderilen bir POST isteğinin yeni bir kullanıcı oluşturduğunu ve doğru yanıtı döndürdüğünü doğrulayın.
Ön koşullar:
- API test ortamı çalışır durumda ve erişilebilir
- Yönetici izinlerine sahip belirteç oluşturuldu ve geçerlidir
- Veritabanında “newuser@testdomain.com” e-posta adresine sahip hiçbir kullanıcı bulunmuyor
| Adım | Beklenen sonuç | Gerçek sonuç | Başarılı/Başarısız |
| Geçerli bir yük ile /api/v1/kullanıcılar adresine POST isteği gönderin: { "name": "Test Kullanıcı", "e-posta": "newuser@testdomain. com", "rol": "viewer" } | Yanıt, kullanıcı ID, adı, e-posta adresi ve rolü içeren bir JSON gövdesi ile birlikte 201 kodunu döndürür. | 201, doğru gövdeyle döndü | Geç |
| Aynı e-posta adresiyle aynı POST isteğini tekrar gönderin | Yanıt, 409 Çakışma hatası ile birlikte şu mesajı döndürüyor: “Bu e-posta adresine sahip bir kullanıcı zaten mevcut” | 200 OK yanıtı döndü; yinelenen kullanıcı oluşturuldu | Başarısız |
| "E-posta" alanı eksikken POST isteği gönderin | Yanıt, “E-posta zorunludur” doğrulama hatasıyla birlikte 400 Hatalı İstek kodunu döndürüyor. | 400, beklendiği gibi döndü | Geç |
| 1. adımdaki ID'yi kullanarak GET /api/v1/users/{id} sorgusunu gerçekleştirin | Yanıt, kullanıcı ayrıntılarının orijinal yükle eşleşmesi durumunda 200 OK değerini döndürür | Beklendiği gibi | Geç |
Sonuç özeti: Uç nokta, kullanıcıları doğru bir şekilde oluşturuyor ve zorunlu alanları doğruluyor, ancak veritabanı düzeyinde e-posta adreslerinin benzersizliğini sağlamıyor. Hata mesajı verilmeden yinelenen kayıtlar oluşturuldu. Hata, "Yüksek" ciddiyet derecesiyle kaydedildi.
Örnek 3: Rol tabanlı erişim kontrolü (güvenlik, izin sınırları)
Bir güvenlik takımı, uyumluluk denetimi öncesinde uygulamanın kullanıcı rollerine göre eylemleri doğru bir şekilde kısıtlayıp kısıtlamadığını test ediyor. Buradaki belirleyici zorluk, bir özelliğin çalışıp çalışmadığını test etmemeniz; bir özelliğin doğru bir şekilde reddedilip reddedilmediğini test etmenizdir. Çoğu adım için beklenen sonuç, başarı değil, bloktur.
Test Uzmanı: Marcus L.
Test tarihi: 09/08/2026
Test senaryosu ID: TC_RBAC_002
Açıklama: "Görüntüleyici" rolüne sahip bir kullanıcının proje oluşturamayacağını, düzenleme yapamayacağını veya silemeyeceğini doğrulayın.
Ön koşullar:
- İki hesap bulunmaktadır: biri “Yönetici” rolüne sahip, diğeri “Görüntüleyici” rolüne sahip
- Çalışma Alanı'nda, Yönetici tarafından oluşturulan en az bir proje bulunmaktadır.
- Görüntüleyen, Firefox 130 ve Windows 11 üzerinde oturum açmış durumda
| Adım | Beklenen sonuç | Gerçek sonuç | Başarılı/Başarısız |
| Projeler sayfasına gidin | Görüntüleyen, proje listesini salt okunur modda görür; “Proje Oluştur” düğmesi ya gizlenmiştir ya da devre dışıdır | Düğme görünür ancak gri renkte | Geç |
| "Proje Oluştur" seçeneğine tıklamayı deneyin | Sistem işlemi engelliyor; yeni proje formu yüklenmiyor | Form yüklenmedi; araç ipucunda “İzininiz yok” yazıyor | Geç |
| Mevcut bir projeyi açın ve başlığı düzenlemeye çalışın | Başlık alanı düzenlenemiyor veya sistem kaydetmeyi engelliyor | Başlık alanı düzenlenebilir durumdaydı; değişiklikler başarıyla kaydedildi | Başarısız |
| Üç nokta menüsünü kullanarak projeyi silmeyi deneyin | Silme seçeneği gizlenmiş veya eylem bir izin hatası nedeniyle bloklanmış | Menüde "Sil" seçeneğinin görünürlüğü yok | Geç |
Sonuç özeti: Görüntüleyenler için oluşturma ve silme izinleri doğru şekilde kısıtlanmıştır, ancak düzenleme izinleri alan düzeyinde uygulanmamaktadır. Bir Görüntüleyen, salt okunur erişime sahip olmasına rağmen proje başlıklarını değiştirebilmektedir. Hata, "Kritik" (uyumluluk engelleyici) ciddiyet derecesiyle kaydedilmiştir.
Test Senaryolarını Yönetmek İçin En İyi Araçlar Nelerdir?
Test senaryoları, özel bir QA aracı (TestRail, Zephyr), genel bir proje yönetimi aracı (ClickUp, Jira) veya bir elektronik tablo ile yönetilebilir; doğru seçim, yerleşik yürütme özelliğine mi yoksa sadece izleme özelliğine mi ihtiyacınız olduğuna bağlıdır.
ClickUp
ClickUp for Software Takımları, test senaryolarının ilgili sprintler, hatalar ve çekme talepleri ile birlikte görevler olarak yer aldığı bir proje yönetimi platformudur. Bu, özel bir test yönetim aracı değildir; ancak esnek görev yapısı, takımların ayrı bir araca ihtiyaç duymadan özel durumlar, alanlar ve görev türlerini kullanarak test senaryosu ş akışları oluşturmasına olanak tanır.
ClickUp'ın ana özellikleri
- Test türü, öncelik ve ortam için özel alanlar içeren, test senaryolarını Alanlar, Klasörler ve Listeler arasında düzenlemenizi sağlayan esnek hiyerarşi
- Durum, atanan kişi veya sprint bazında test yürütülmesini izlemek için 15'ten fazla ClickUp Görünümü (Pano, Liste, Tablo)
- PRD'leri, test planlarını ve ortam kurulum kılavuzlarını, bunlara dayanak teşkil eden test senaryolarının yanında tutmaya yönelik belgeler
- Slack veya e-postaya geçmenize gerek kalmadan QA ve geliştiriciler arasında iletişim kurmanızı sağlayan yerleşik sohbet özelliği
- Sprint incelemeleri sırasında hızlı bir bağlam elde etmek için ClickUp Brain aracılığıyla sunulan yapay zeka destekli görev özetleri
ClickUp'ın sınırlamaları
- Yerel test yürütme motoru yok
- Teste özgü raporlar (gereksinimlere göre kapsam, döngü başına başarı oranı), hazır QA raporları yerine özel gösterge panellerine ihtiyaç duyar.
ClickUp fiyatlandırması
ClickUp puanları ve yorumları
- G2: 4,6/5 (14.100'den fazla yorum)
- Capterra: 4,6/5 (4600'den fazla yorum)
Gerçek kullanıcılar ClickUp hakkında ne diyor?
İşte bir G2 yorumcusunun görüşü:
ClickUp'ta en çok sevdiğim şey, her şeyi tek bir yerde bir araya getirmesidir. Görevler, zaman çizelgeleri, notlar ve güncellemeler aynı sistemde bulunur, bu da araçlar arasında gidip gelme ihtiyacını azaltır. Esnekliğini de çok değerli buluyorum. Durumları, alanları ve görünümleri takımımızın gerçek çalışma şekline uyacak şekilde özelleştirebiliyoruz. Bu, düzenli kalmayı kolaylaştırıyor ve herhangi bir anda kimin neyden sorumlu olduğu ve projelerin hangi aşamada olduğu konusunda net bir görünürlük sağlıyor.
ClickUp'ta en çok sevdiğim şey, her şeyi tek bir yerde bir araya getirmesidir. Görevler, zaman çizelgeleri, notlar ve güncellemeler aynı sistemde bulunur; bu da araçlar arasında gidip gelme ihtiyacını azaltır. Esnekliğini de çok takdir ediyorum. Durumları, alanları ve görünümleri takımımızın gerçek çalışma şekline uyacak şekilde özelleştirebiliyoruz. Bu, düzenli kalmayı kolaylaştırıyor ve herhangi bir anda kimin neyden sorumlu olduğu ile projelerin hangi aşamada olduğu konusunda net bir görünürlük sağlıyor.
En uygun kullanım alanı: Başarısız bir testin tek bir tıklamayla geliştiricinin hata biletine dönüşmesini isteyen ve PR, test adımları ile sprintin hepsinin aynı görevden görünür olmasını isteyen bir QA lideri.
Şu durumlarda atlayın: Test döngünüz büyük ölçüde otomasyonla gerçekleştirilmişse. Test paketinizin %80'i bir CI boru hattından çalışıyorsa, bir kişinin durumu güncellediği bir araca değil, yürütme sonuçlarını otomatik olarak alan bir araca ihtiyacınız vardır.
TestRail
TestRail, test sürecinin tamamı üzerinde yapılandırılmış bir kontrole ihtiyaç duyan kalite güvence (QA) takımları için geliştirilmiş özel bir test yönetim platformudur. DevOps ve CI/CD entegrasyonları sayesinde sonuçları besleyerek test senaryolarının yazılması, çalıştırılması ve raporlanmasından oluşan tam döngüyü yönetir.
TestRail'in anahtar özellikleri
- Projeler arasında yeniden kullanılabilir test senaryoları ile merkezi test senaryosu ve test paketi yönetimi
- Sprintler ve sürümler genelinde test çalıştırmalarını düzenlemek ve planlamak için test planları ve dönüm noktaları
- Kapsam analizi, ilerleme izleme ve yürütme geçmişini içeren ayrıntılı raporlama
- Jira, GitHub, Jenkins, Azure DevOps ve 20'den fazla diğer DevOps aracıyla entegrasyonlar
- Görevleri otomasyon için kullanmak ve test verilerini harici sistemlerle senkronizasyon yapmak için REST API
TestRail sınırlamaları
- Yerel gereksinim veya sorun izleme özelliği bulunmadığından, takımlar Jira gibi harici araçlara güvenmek zorundadır ve bu da izlenebilirliği parçalayabilir
- Test depoları binlerceye ulaştıkça, klasör tabanlı düzenlemede gezinmek zorlaşır
TestRail fiyatlandırması
- Profesyonel: 39 $/kullanıcı/ay
- Enterprise: 78 $/kullanıcı/ay
TestRail puanları ve yorumları
- G2: 4,4/5 (600'den fazla yorum)
- Capterra: 4,3/5 (160'dan fazla yorum)
Gerçek kullanıcılar TestRail hakkında ne diyor?
İşte bir G2 yorumcusunun görüşü:
TestRail hakkında en değerli bulduğum şey, QA takımımıza test planlarını, test senaryolarını ve test çalıştırmalarını yönetmek için güvenlikli ve iyi organize edilmiş bir ortam sağlamasıdır. Test takımlarını yapılandırmanın ve uygulamanın yanı sıra, daha önce oluşturulmuş test senaryolarını yeniden kullanmanın ne kadar kolay olduğunu takdir ediyorum. Jira ve CI/CD araçlarıyla entegrasyonlar, ş akışımızı daha uyumlu hale getirdi ve izlemeyi kolaylaştırdı. Test ilerlemesini ve kapsamını gerçek zamanlı olarak izleyebilme özelliği, sprint planlaması ve raporlama için inanılmaz derecede yardımcı oldu. Bir QA Mühendisi olarak günlük işlerimde TestRail’i kullanmak bana önemli ölçüde zaman kazandırdı.
TestRail hakkında en değerli bulduğum şey, QA takımımıza test planlarını, test senaryolarını ve test çalıştırmalarını yönetmek için güvenli ve iyi organize edilmiş bir ortam sağlamasıdır. Test takımlarını yapılandırmanın ve uygulamanın yanı sıra, daha önce oluşturulmuş test senaryolarını yeniden kullanmanın ne kadar kolay olduğunu takdir ediyorum. Jira ve CI/CD araçlarıyla entegrasyonlar, ş akışımızı daha uyumlu hale getirdi ve izlemeyi kolaylaştırdı. Test ilerlemesini ve kapsamını gerçek zamanlı olarak izleyebilme özelliği, sprint planlaması ve raporlama için inanılmaz derecede yardımcı oldu. Bir QA Mühendisi olarak günlük işlerimde TestRail'i kullanmak bana önemli ölçüde zaman kazandırdı.
En uygun kullanım alanı: Her sürüm için resmi test döngüleri yürüten beş veya daha fazla kişiden oluşan bir QA takımı; bu durumda yöneticinin, bir elektronik tablo yerine bir gösterge panelinden “Sürüm 2.0’ın yüzde kaçı yürütüldü ve başarılı oldu?” sorusuna yanıt vermesi gerekir.
Aşağıdaki durumlarda atlayın: Test paketiniz birkaç yüz senaryodan azsa veya test uzmanlarınız aynı zamanda geliştirici olarak da çalışıyorsa. Bu ölçekte, kullanıcı başına maliyet ve ayrı oturum açma, size bakmayacağınız raporlama özellikleri için ek masraf yaratır.
Zephyr
Zephyr, Jira arayüzü içinden test senaryolarını yönetmek üzere tasarlanmış, SmartBear’ın Jira için sunduğu test yönetimi eklentisidir. Hem manuel hem de otomasyonlu testleri destekler ve çevik ve kurumsal takımlar için güçlü raporlama ve izlenebilirlik özellikleri sunar.
Zephyr'ın ana özellikleri
- Jira ile yerel entegrasyon: test senaryolarını doğrudan Jira sorunlarından oluşturun, bağlayın ve çalıştırın
- Test senaryolarını büyük ölçekte yeniden kullanmak ve düzenlemek için projeler arası hiyerarşik test kütüphaneleri
- Test kapsamı, yürütme ilerlemesi ve hata izlemesini kapsayan 70'in üzerinde kullanıma hazır rapor
- Davranış odaklı geliştirme ş akışları için Gherkin sözdizimi ile BDD destek
- Jenkins, GitHub, GitLab, Bitbucket ve Bamboo ile CI/CD entegrasyonları
Zephyr'in sınırlamaları
- Tester başına değil, Jira kullanıcısı başına lisanslanır
- Büyük test depoları (binlerce test senaryosu), TestRail gibi bağımsız araçlara kıyasla gezinmesi daha zor gelebilir
- Destek, Atlassian Marketplace üzerinden sağlanır; bu da doğrudan satıcı desteğine alışkın takımlar için ek bir katman oluşturur
Zephyr fiyatlandırması
- Essential: Kullanıcı başına aylık 5,99 $'dan başlayan fiyatlarla (11-50 kullanıcı)
- Standart: Kullanıcı başına aylık 6,81 $'dan başlayan fiyatlarla (11-50 kullanıcı)
- Gelişmiş: Kullanıcı başına aylık 8,73 $'dan başlayan fiyatlarla (11-50 kullanıcı)
Zephyr puanları ve yorumları
- G2: 4,1/5 (80'den fazla yorum)
- Capterra: Yeterli sayıda yorum yok
Gerçek kullanıcılar Zephyr hakkında ne diyor?
İşte bir G2 yorumcusunun görüşü:
Bu, test senaryolarını doğrudan Excel tablosundan içe aktarmak için en iyi araçtır. Bu aracı kullanarak test uzmanlarının iş yükü, Jira'ya test senaryolarını içe aktarmaya kıyasla daha az oluyor. Ayrıca, bu aracın en iyi özelliklerinden biri, test senaryolarını başarılı veya başarısız olarak işaretleyebilme ve ek dosya ekleyebilme imkanıdır.
Bu, test senaryolarını doğrudan Excel tablosundan içe aktarmak için en iyi araçtır. Bu aracı kullanarak test uzmanlarının iş yükü, Jira'ya test senaryolarını içe aktarmaya kıyasla daha az oluyor. Ayrıca, bu aracın en iyi özelliği, test senaryolarını başarılı veya başarısız olarak işaretleyebilme ve ek dosya ekleyebilme imkanıdır.
En uygun olduğu durumlar: Her testin bir Jira gereksinimine kadar izlenebilmesini ve her hatanın onu tespit eden teste bağlanabilmesini gerektiren, düzenlemelere tabi veya denetim yükü ağır olan takımlar (fintech, sağlık sektörü); tüm bunlar tek bir Atlassian örneğinde gerçekleştirilir.
Şu durumlarda atlayın: Jira örneğiniz büyük ve QA takımınız küçükse. 10 test uzmanı bulunan 200 lisanslı bir Jira, kimsenin açmadığı 190 Zephyr lisansının ücretini karşılar; test uzmanı başına fiyatlandırılan bağımsız bir araç daha ucuza gelir.
Jira
Jira, Atlassian’ın proje yönetimi ve sorun izleme platformudur; mühendislik ve kalite güvencesi takımları tarafından sprintleri, hataları ve geliştirme akışlarını yönetmek için yaygın olarak kullanılır. Her ne kadar özel bir test yönetimi aracı olmasa da, birçok takım mevcut Jira kurulumları içinde test senaryosu yönetimini yürütmek için Zephyr Scale veya Xray gibi çözümlerle birlikte Jira’yı kullanır.
Jira'nın ana özellikleri
- Sprintleri, birikmiş işleri ve Agile test akışlarını yönetmek için Scrum ve Kanban panoları
- Takımın işleri izleme şekline uyacak şekilde özelleştirilebilir ş akışları, sorun türleri ve alanlar
- Takımlar arası planlama ve bağımlılık izleme için Gelişmiş Yol Haritaları (Premium)
- GitHub, Confluence, Slack ve CI/CD araçları dahil olmak üzere 1.000'den fazla pazar yeri entegrasyonu
- Sorun güncellemelerine veya durum değişikliklerine göre projeler genelinde eylemleri tetikleyen otomasyon kuralları
Jira'nın sınırlamaları
- Test senaryosu yönetimi, Jira aboneliğinin yanı sıra kullanıcı başına ayrı bir ücreti olan bir Marketplace eklentisi (Zephyr Scale, Xray) gerektirir.
- Teknik bilgisi olmayan kullanıcılar için öğrenme eğrisi daha diktir ve büyük takımlarda işe alım maliyetleri artabilir
Jira fiyatlandırması
- Ücretsiz
- Standart: 7,91 $/kullanıcı/ay
- Premium: 14,54 $/kullanıcı/ay
- Kurumsal: Özel fiyatlandırma
Jira puanları ve yorumları
- G2: 4,3/5 (7.900'den fazla değerlendirme)
- Capterra: 4,4/5 (15.400'den fazla yorum)
Gerçek kullanıcılar Jira hakkında ne diyor?
İşte bir G2 yorumcusunun görüşü:
Jira, iş takımımın tüm üyeleriyle işbirliği içinde tüm iş projelerimin performansını izlemek ve görselleştirmek için favori dijital programlardan biridir; çünkü kendi sınıfında en iyi sanal performans yeteneklerini sunarak tüm mesleki hedeflerime ulaşmamı kolaylaştırır.
Jira, iş takımımın tüm üyeleriyle işbirliği içinde tüm iş projelerimin performansını izlemek ve görselleştirmek için favori dijital programlardan biridir; çünkü sınıfının en iyi sanal performans özelliklerini sunarak tüm mesleki hedeflerime ulaşmamı kolaylaştırır.
En uygun kullanım alanı: Özel bir test yönetimine gerçekten ihtiyaç duyup duymadıklarını değerlendiren mühendislik takımları. Öncelikle birkaç test döngüsünü özel Jira sorun türleri olarak yürütmek, iş hacminin bir eklentiyi kullanmayı haklı kılıp kılmadığını gösterir.
Şu durumlarda atlayın: Test yönetimine ihtiyacınız olduğunu zaten biliyorsanız. Doğrudan bir eklentiye veya bağımsız bir araca geçmek, özel sorun türleri ölçeklenemez hale geldiğinde geçiş sürecinden kurtulmanızı sağlar.
Test Senaryoları Oluştururken Kaçınılması Gereken Yaygın Hatalar
Genel etkinliğini azaltabilecek bu test senaryosu yazma hatalarından kaçının.
| Hata | Bunun yerine yapılacaklar |
|---|---|
| Test senaryolarını çok geç yazmak | Kodlama başlamadan önce olası sorunları tespit etmek için test uzmanlarını gereksinim belirleme ve tasarım aşamalarına dahil edin |
| Test senaryoları güncellenmiyor | Özellik yeni bir güncelleme aldığında, fonksiyonunda bir değişiklik olduğunda veya kullanıcı arayüzünde bir değişiklik olduğunda test senaryosunu derhal güncelleyin |
| Son koşul yok | Test tamamlandıktan sonra sistemin nasıl görünmesi gerektiğini (test kullanıcısının silinmesi, sepetin boşaltılması, oturumun kapatılması) belirtin, böylece bir sonraki senaryo temiz bir durumdan başlasın |
| Yalnızca normal senaryo verileri | Her giriş alanının, sistem tarafından reddedilmesi gereken en az bir değere sahip olması gerekir. Veri kümesinin nasıl oluşturulduğunu veya alındığını belgelendirin |
| Test senaryolarına öncelik vermemek | Her test senaryosuna iş üzerindeki etkisi, kullanım sıklığı ve başarısızlık riskine göre bir öncelik atayın. Bu, test çabalarınızı odaklamanıza ve bütçe ile test yöntemleri konusunda daha akıllı kararlar almanıza yardımcı olur. |
Test Senaryolarının Zaman İçinde Yararlı Kalmasını Sağlama
Bir test paketi, her bir test senaryosunun bağımsız olması, hataya yol açma olasılığı en yüksek girdileri hedeflemesi ve güvenilir bir sonuç veremediği anda kullanımdan kaldırılması durumunda güvenilirliğini korur. Bu altı uygulama, yıllarca hataları tespit eden test paketlerini, ikinci sprintten sonra göz ardı edilen test paketlerinden ayırır.
Bağımsız, atomik testler yazın
Bir test senaryosu kendi durumunu kendiliğinden oluşturmalı ve asla daha önce çalıştırılmış başka bir senaryoya bağımlı olmamalıdır. TC_CHECKOUT_003, TC_CHECKOUT_002'nin sepete bir öğe bıraktığını varsaydığında, tek bir hata beş hataya yol açar ve siz de sabahınızı hangi hatanın gerçek olduğunu bulmaya çalışarak geçirirsiniz. Bir test başlığında "ve" kelimesi gerekiyorsa, bunu iki senaryoya bölün.
Sınırlarda test yapın
Hatalar, kabul edilen girdilerin ortasında değil, sınırlarında yoğunlaşır. Bir şifre alanı 8 ila 128 karakter kabul ediyorsa, sadece 12 karakterlik rahat bir şifreyi değil, 7, 8, 128 ve 129 karakterlik şifreleri de test edin. Sınır değeri analizi, tam da bu nedenle ISO/IEC/IEEE 29119-4 test tasarımı standardında yer alan resmi bir tekniktir: rastgele girdilerin gözden kaçırdığı "bir birim sapma" hatalarını bulur.
Eşdeğerlik bölümlemesini kullanarak gereksiz senaryoları ortadan kaldırın
Sistemin aynı şekilde işlemesi gereken girdileri gruplandırın, ardından her gruptan birer temsilciyi test edin. Her geçerli e-posta biçimi, oturum açma formunda aynı şekilde davranır; bu nedenle tek bir geçerli e-posta yeterlidir. user@example.com, jane@company.com ve bob@domain.org adreslerini üç ayrı senaryo olarak test etmek, kapsama alanını artırmadan bakım yükünüzü üç katına çıkarır.
Test verilerini test adımlarından ayırın
Bir adıma “test@example.com girin” ifadesini sabit olarak yazmak, test ortamı her değiştiğinde adımı yeniden yazmak anlamına gelir. Adımları genel tutun (“kayıtlı bir e-posta adresi girin”) ve gerçek değerleri bir test veri alanında veya dosyasında saklayın. Böylece aynı adımlar, düzenleme yapılmasına gerek kalmadan staging, QA ve ön üretim ortamlarında çalıştırılabilir ve negatif test için yeni bir veri kümesi eklemek tek satırlık bir değişiklikle halledilebilir.
Kararsız testleri ve hata kaçış oranını izleme
Kararsız bir test, gerçek bir ürün hatası olmaksızın tutarsız bir şekilde başarısız olur ve her kararsız test, takıma kırmızı sonuçları görmezden gelmeyi öğretir. Her bir test senaryosunun, aynı derlemelerde ne sıklıkla başarılı ve başarısız sonuçlar arasında değiştiğini izleyin. Bir test senaryosu ayda birkaç kereden fazla kararsız sonuç veriyorsa, onu yeniden yazın veya kaldırın. Bunu, hata kaçış oranıyla (bir test senaryosunun yakalaması gereken ancak üretim ortamında bulunan hatalar) birleştirerek, kapsama alanının sadece gürültülü olduğu yerleri değil, zayıf olduğu yerleri de belirleyin.
En sık çalıştırdığınız testleri otomasyonla otomatikleştirin
Regresyon, duman testi ve yüksek sıklıklı fonksiyonel test senaryoları, her derlemede çalıştırıldıkları ve nadiren değiştiği için otomasyon için en uygun adaylardır. Bunları CI/CD boru hattınızdaki komut dosyalarına taşıyın ve kullanıcı arayüzü öğelerinin sık sık yer değiştirdiği yerlerde, kendi kendini onaran konum belirleyicilere sahip yapay zeka destekli araçlar kullanın. Bu, insan test uzmanlarını keşifsel işlere ve kullanılabilirlik ile sınır durumlarının tespiti gibi muhakeme gerektiren yazılım testlerine yönlendirecektir.
ClickUp'ta Test Senaryoları Nasıl Yazılır ve Çalıştırılır?
Yukarıdaki araçlar bölümü, ClickUp'ın hangi aşamalarda kullanılabileceğini ele almaktadır. Bu bölümde ise, kılavuzun önceki bölümlerinde anlatılan adımlara göre düzenlenmiş gerçek kurulum süreci gösterilmektedir.
Test senaryosu kütüphanenizi yapılandırın. Ürününüz için bir Alan, her bir özellik alanı için bir Klasör (örn. Kimlik Doğrulama, Ödeme, Kullanıcı Kaydı) ve her test döngüsü veya sprint için bir Liste oluşturun. Her görev, ayrı bir test senaryosu haline gelir. ClickUp Özel Alanlarını kullanarak test senaryosu Kimliği, ön koşullar, test verileri, öncelik düzeyi ve ortam gibi bileşenleri kaydedin.
Test adımlarını doğrudan görev içine yazın. Görev açıklamasını kullanarak sıralı yürütme adımlarını ve beklenen sonuçları belgelendirin. Kontrol listeleri, test uzmanının her eylemi işaretlemesi gereken adım adım akışlar için çok kullanışlıdır; açıklama bölümü ise ön koşullar ve test verileri gibi bağlam bilgilerini içerir.
Yürütme ve sonuçları takip edin. Test akışınızı yansıtan Özel Durumlar oluşturun: Başlamadı → İlerleme → Başarılı → Başarısız → Engellendi. Bir test başarısız olduğunda, onu bir hata görevine dönüştürün veya geliştiriciye atanan, öncelik, bağımlılıklar ve son tarih içeren bağlantılı bir görev oluşturun. GitHub ve GitLab entegrasyonları, bu hatayı doğrudan onu ortaya çıkaran PR'ye bağlamanıza olanak tanır. Temel neden bir kod hatasıysa, bu hata görevini ClickUp Codegen Agent'a atayabilirsiniz; bu araç, görev açıklamasını, bağlantılı teknik özellikleri ve yorumları okur, önerilen bir düzeltme yazısı hazırlar ve inceleme için bir Çekme Talebi açar; ilerleme durumu da göreve geri bildirilir.
Profesyonel İpucu: Kalite güvencesi (QA) liderleri, ClickUp Brain'den açık hata görevlerini özetlemesini isteyerek herhangi bir görevin anlık bir özetini alabilir. Bu sayede, durumu anlamak için tek tek görevleri tek tek incelemek zorunda kalmadan, sprint incelemeleri için ihtiyaç duydukları tüm bağlam bilgisine sahip olurlar.
Görünümlerle test döngüleri çalıştırın. Test çalıştırması sırasında başarılı/başarısız dağılımını bir bakışta görmek için duruma göre gruplandırılmış Pano Görünümü'nü kullanın. Onlarca test senaryosundaki sonuçları taramanız gerektiğinde Tablo Görünümü geleneksel bir test matrisi gibi çalışır. İş yükünü dengelemek için atanan kişiye göre veya öncelikle kritik yollara odaklanan bir hızlı test yapmak için önceliğe göre filtreleme yapın.
ClickUp Test Yönetimi Şablonu, birden fazla özellik alanı, test senaryosu ve sınır durumlarını kapsayan tüm test akışını tek bir yerden merkezi olarak yönetmenizi sağlar. Bu şablonu kullanarak, farklı araçlar arasında geçiş yapmaya gerek kalmadan kullanıcı geri bildirimlerini izleyin, test programlarını yönetin, testlerin ilerleyişini izleyin ve başarılı/başarısız sonuçlarını değerlendirin.
Test Akışlarınızı Etkili Bir Şekilde Yönetin
Bir test senaryosu, iki kişinin onu bağımsız olarak çalıştırıp aynı "başarılı" veya "başarısız" sonucuna ulaştığı anda geçerliliğini kazanır. Bu kılavuzdaki her şey (her adımda tek bir eylem, açık ön koşullar, yoruma yer bırakmayan beklenen sonuçlar) bu tek standarda hizmet eder. Zaten ClickUp'ta sprint planlaması yapıyorsanız, yukarıda anlatılan kurulum sayesinde başka bir araç eklemeye gerek kalmadan test senaryolarını yazabilir, çalıştırabilir ve ortaya çıkardıkları hatalarla birlikte izleme yapabilirsiniz.
Test Senaryoları Hakkında Sık Sorulan Sorular
Bir gereksinim kaç tane test senaryosuna sahip olmalıdır?
Tek bir gereksinim, içerdiği senaryo, uç durum ve girdi varyasyonlarının sayısına bağlı olarak bir test senaryosuna ya da on tanesine ihtiyaç duyabilir. Buradaki amaç, tüm gerçekçi yolları kapsamak ve gereksiz tekrarlar olmadan yeterli kapsam sağlamak.
Test senaryoları ile test komut dosyaları arasındaki fark nedir?
Bir test senaryosu, manuel olarak yürütülmek üzere yazılmış olup, neyin test edileceğini ve hangi sonucun beklendiğini belgeler. Öte yandan, bir test komut dosyası ise bunun otomatikleştirilmiş sürümüdür: aynı adımları programlı olarak yürüten koddur.
Test adımları ne kadar ayrıntılı olmalıdır?
Testi, önceden bilgi sahibi olmaksızın takip edilmesi kolay, mantıklı ve sıralı adımlara bölün. Birden fazla eylemi bir araya toplamayın veya gereksiz karmaşıklık eklemeyin.
Bir test senaryosu, tek bir satırda neyin test edileceğini belirtir (“Şifre sıfırlamasını doğrula”); bir test senaryosu ise ön koşullar, adımlar, test verileri ve beklenen sonuçlarla nasıl test edileceğini belirtir. Bir senaryo genellikle normal akış, geçersiz girdiler ve sınır koşullarını kapsayan 3 ila 10 test senaryosu üretir. Senaryolar ilk sırada gelir ve kapsama planlamasını yönlendirir; test senaryoları ise ikinci sırada gelir ve yürütmeyi yönlendirir.
Olumlu bir test senaryosu geçerli girdiler kullanır ve başarıyı bekler: doğru e-posta adresi ve şifre ile kullanıcı oturum açar. Olumsuz bir test senaryosu ise geçersiz veya beklenmedik girdiler kullanır ve sistemin hatayı düzgün bir şekilde işleyerek başarısız olmasını bekler: yanlış şifre girildiğinde, oturum açılmadan “Geçersiz şifre” mesajı görüntülenir. Olgun test takımlarında olumlu ve olumsuz testlerin oranı yaklaşık 1:3 ile 1:5 arasındadır; çünkü üretim ortamındaki hataların çoğu, sorunsuz senaryolarda değil, hata senaryolarında ortaya çıkar.
Bir test planı, tüm test çabasının kapsamını, yaklaşımını, kaynaklarını ve zamanlamasını tanımlar. Test paketi ise, tek bir çalıştırma için gruplandırılmış test senaryolarının bir koleksiyonudur; örneğin, “2.1 sürümü için regresyon paketi”. Test senaryosu ise her ikisinin de içindeki temel birimdir: tek bir başarılı/başarısız sonucuna sahip, belgelenmiş bir kontrol. Plan stratejiyi belirler, paket kapsamı belirler, senaryo ise sonucu belirler.