Çoğu test senaryosu, tek bir hata bile yakalayamadan başarısız olur. Bu senaryolar, belirsiz kontrol listeleri olarak 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ı” teriminin ne anlama geldiği konusunda anlaşamaz. Sonuç olarak: hatalar gözden kaçar, test çalıştırmaları tekrarlanamaz ve kalite güvencesi bir güvenlik ağı yerine bir darboğaz haline gelir.
İyi bir test senaryosu yazmak, test becerisinden çok doğrulama tasarımıyla ilgilidir. Finansal hizmetler sektöründe buna "yapıcı-denetleyici 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 denetlenmemiş eyleme dayandırılmamalıdır. İyi yazılmış bir test senaryosu, yazılımda da aynı titizliği sağlar. Beklediğiniz ile gözlemlediğiniz şeyleri birbirinden 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 birinin, sonucun kontrol edilebilmesi için benzersiz bir ID, ön koşullar ve beklenen sonuçlar içermesi gerekir. Bu kılavuz, yedi adımlı yazma sürecini, üç uygulamalı örneği ve ürün değiştikçe test takımının güvenilirliğini nasıl koruyacağınızı ele almaktadır.
Test Senaryoları Nedir?
Test senaryosu, belirli bir yazılımın doğru ç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. Bu, bir test planı (test stratejisini özetleyen) veya bir test komut dosyası (adımları programlı olarak yürüten otomatik bir 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 tepkilerini tanımlayan 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ğerler içeren veriler girin
Manuel ve Otomasyonlu Test Senaryolarının Karşılaştırması
Yapay zeka artık çoğu test akışının bir parçası haline gelmiştir. PractiTest’in 2026 Test Durumu Raporu’na göre, test uzmanlarının %76,8’i kalite güvencesi sürecinde yapay zeka kullanmaktadır; test senaryosu oluşturma (%69,6) ve komut dosyası bakımı (%59,6) ise en yaygın iki kullanım alanıdır. Bu değişim en çok otomasyonlu test senaryolarında göze çarpmaktadır; bu nedenle, bunların manuel test senaryolarından ne şekilde 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 | İnsanların verileri manuel olarak girmesi ve sonuçları doğrulaması gerektiğinden, bu süreç yavaş ve zaman alıcı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ı zor | 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ı Neden Önemlidir?
Kullanıcılar sorun bildirimi göndermeden önce regresyon hatalarını yakalayın. Her kod değişikliği, halihazırda çalışan bir şeyi bozma riskini beraberinde getirir. İyi yazılmış bir test senaryosu, her dağıtımdan sonra çalıştırılan 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 staging ortamında sorunu tespit eder.
Başarılı/başarısız sonucunu 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; bunun için 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 indirgeyin. Bir test senaryosu “sayfaya git, kimlik bilgilerini gir ve gönder’i tıkla” işlemlerini tek bir adımda topladığında 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 ise, 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, hatayı tam olarak hangi etkileşimin tetikleyici olduğunu bilir.
Nelerin kapsandığını ve nelerin gözden kaçtığını görebilirsiniz. Yapılandırılmış test senaryoları olmadan, test kapsamı sadece bir tahmindir. Bunlar sayesinde, her senaryoyu bir gereksinime bağlayabilir 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, birden fazla istek) ve bunlardan sadece üçü için test senaryolarınız varsa, bu eksiklik hem görünür hem de ölçülebilir hale gelir. Bu görünürlük, test sürecini “bunu test ettik” yaklaşımından “işte tam olarak neyi test ettik, neyi test etmedik ve kabul ettiğimiz risk budur” yaklaşımına dönüştürür.
İyi Bir Test Senaryosunun Bileşenleri
Kullanışlı bir test senaryosu, sadece neyin test edileceğini açıklamakla kalmaz. Bağlamı, yürütme adımlarını ve beklenen sistem davranışını da kapsar; böylece başka bir test uzmanı, yazılım geliştirici veya ürün yöneticisi testi tekrarlayabilir ve sonucu doğrulayabilir.
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 yaptığımız paylaşımda sunduğumuz 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 bu senaryoları 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 zaten 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, özellik doğru şekilde çalışıyorsa 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 girdiniz ancak “Geçersiz şifre” hata mesajı aldınız
Şimdi test senaryosu yazma becerilerinizi uygulamaya 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 etmek, senaryoları listelemek, yapıyı planlamak, beklenen sonuçlarla birlikte adımları yazmak, ek dosya eklemek, incelettirmek, ardından yürütmek ve kaydetmek.
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 unuttuğunda hesabına yeniden erişebilir mi?
- Kullanıcı hangi işlemleri gerçekleştirebilir, örneğin sıfırlama bağlantısı talep edebilir, 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 şartlarını 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.
Amaç: 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 edip 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 bloklediğini 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ışları hem de gerçek kullanıcıların kaçınılmaz olarak karşılaşacağı sınır durumlarını kapsayan bir 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
Tekrarlanan 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 uygulamanızı planlayın:
Testi kim gerçekleştirecek?
Bu testi yürüten kişinin hangi rolle veya niteliklerle donanmış olması gerekir? 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 fonksiyonel ve regresyon testleri
- Güvenlik takımı: Kimlik doğrulama, erişim kontrolü veya veri sızıntısı güvenlik açıklarını içeren testler
- Geliştirici: Parola 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ı mevcut
- Kullanıcının sistemden oturumu kapatıldı
- E-posta hizmeti aktif ve mesajları iletebiliyor
- Test ortamına erişim sağlanabilir 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ğerler.
Ö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 minimum karakter sınırının altında
- Sınır: Şifre, tam olarak minimum ve maksimum karakter sınırında olmalı
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ına dikkat edin. 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 talebi sayfasına yönlendirilir |
| E-posta alanına e-posta adresinizi girin | E-posta adresi, doğrulama hatası olmadan kabul edildi |
| “Sıfırlama Bağlantısını Gönder” seçeneğine 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 hiç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 beklenebileceğ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
Yazdığınız test senaryosunu, çalıştırmadan önce bir meslektaşınızla veya kıdemli bir kalite güvence lideriyle paylaşın. İnceleme sırasında şunlara dikkat 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 sonucu (bir mesaj, bir yönlendirme, bir durum kodu) belirtir.
- 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 test 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ğrulama yaptığı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 akışını test ediyor. Akış birden fazla sayfayı kapsıyor: sepet → kargo → ödeme → onay. 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 (sepet 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 adet kaydedilmiş kredi kartı ve bir adet kaydedilmiş teslimat adresi bulunmaktadır
- En az bir öğe stokta mevcut ve sepete eklendi
- Test ortamı Chrome 128 ve macOS üzerinde çalışıyor
| Adım | Beklenen sonuç | Gerçek sonuç | Başarılı/Başarısız |
| Sepet sayfasına gidin | Sepette doğru öğe, miktar ve ara toplam görüntüleniyor | Beklendiği gibi | Geç |
| "Ödemeye Devam Et" düğmesine tıklayın | Sayfa, kaydedilmiş adres önceden seçili olarak yüklenir | Beklendiği gibi | Geç |
| "Standart Kargo" seçimini yapın ve "Devam Et" düğmesine 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 yönetiyor, 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ışıyor ve erişilebilir durumda
- 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 201 Created 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" geçerlilik 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 kodunu 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 vermeden yinelenen kayıtlar oluşturuldu. Hata, "Yüksek" önem 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 ş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 şekilde engellenip engellenmediğini test etmenizdir. Çoğu adım için beklenen sonuç, başarı değil, engellemedir.
Test Uzmanı: Marcus L.
Sınav 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 ise “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 | Kullanıcı, 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" düğmesine tıklamayı deneyin | Sistem işlemi engelliyor; yeni proje formu yüklenmiyor | Form yüklenmedi; araç ipucunda “İzin yok” yazıyor | Geç |
| Mevcut bir projeyi açın ve başlığı düzenlemeyi deneyin | Başlık alanı düzenlenemez veya sistem kaydetmeyi blokluyor | Başlık alanı düzenlenebilir durumdaydı; değişiklikler başarıyla kaydedildi | Başarısızlık |
| Üç nokta menüsünü kullanarak projeyi silmeyi deneyin | Silme seçeneği gizli 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ştirebilir. Hata, ciddiyet derecesi "Kritik" (uyum engeli) olarak kaydedilmiştir.
Test Senaryolarını Yönetmek İçin En İyi Araçlar Nelerdir?
Test senaryoları, özel bir kalite güvence aracında (TestRail, Zephyr), genel bir proje yönetimi aracında (ClickUp, Jira) veya bir elektronik tabloda 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ı sayesinde takımlar, ayrı bir araca ihtiyaç duymadan özel durumlar, alanlar ve görev türlerini kullanarak test senaryosu ş akışları oluşturabilir.
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üzenlemeye olanak tanıyan esnek hiyerarşi
- Durum, atanan kişi veya sprint bazında test yürütmesini 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'e veya e-postaya geçmeden QA ve geliştiriciler arasında iletişim kurmak için yerleşik sohbet özelliği
- Sprint incelemeleri sırasında hızlı bir bağlam elde etmek için ClickUp Brain aracılığıyla yapay zeka destekli görev özetleri
ClickUp'ın sınırlamaları
- Yerel test yürütme motoru yok
- Teste özgü raporlar (gereksinim bazında kapsama oranı, döngü başına başarı oranı) için hazır QA raporları yerine özel gösterge panelleri gerekir.
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 getirmesi. Görevler, zaman çizelgeleri, notlar ve güncellemeler aynı sistemde yer alıyor; bu da araçlar arasında gidip gelme ihtiyacını ortadan kaldırıyor. 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 sayede düzenli kalmak daha kolay oluyor ve herhangi bir anda kimin neyden sorumlu olduğu ile projelerin hangi aşamada olduğu net bir şekilde görülebiliyor.
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 yer alır, bu da araçlar arasında gidip gelme ihtiyacını azaltır. Esnekliğini de çok değer veriyorum. 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ı: Tek bir tıklamayla başarısız bir testin geliştiricinin hata biletine dönüşmesini isteyen, aynı görevden PR, test adımları ve sprint bilgilerini tek bir yerden görebilen bir kalite güvence lideri.
Aşağıdaki durumlarda atlayın: Test döngünüz büyük ölçüde otomasyonla gerçekleştiriliyorsa. Test takımınızın %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, tüm test süreçleri üzerinde yapılandırılmış bir kontrol gerektiren kalite güvence takımlarına yönelik olarak geliştirilmiş özel bir test yönetim platformudur. Test senaryolarının yazılması, çalıştırılması ve raporlanması döngüsünün tamamını yönetir; ayrıca DevOps ve CI/CD entegrasyonları sayesinde sonuçları platforma aktarır.
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 boyunca 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şi 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 senkronize etmek için REST API
TestRail'in sınırlamaları
- Yerel gereksinim veya sorun izleme özelliği bulunmadığından, takımlar Jira gibi harici araçlara güvenmek zorundadır; 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
- Kurumsal: 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ü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. Kalite güvence 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üvenlikli ve iyi organize edilmiş bir ortam sunması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 tutarlı 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. Kalite güvence 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 kalite güvence 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 geçti?” sorusuna yanıt vermesi gerekir.
Aşağıdaki durumlarda bu kursu atlayın: Test paketiniz birkaç yüz senaryodan azsa veya test uzmanlarınız aynı zamanda yazılım geliştirici olarak da çalışıyorsa. Bu ölçekte, kullanıcı başına maliyet ve ayrı oturum açma, size bakmayacağınız raporlar için para harcamak anlamına gelir.
Zephyr
Zephyr, Jira arayüzünden test senaryolarını yönetmek üzere tasarlanmış, SmartBear’ın Jira için geliştirdiği test yönetimi eklentisidir. Hem manuel hem de otomasyonlu testleri destekleyen bu eklenti, ç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ı
- Lisans, test uzmanı başına değil, Jira kullanıcısı başına verilir
- Büyük test depolarında (binlerce test senaryosu) gezinmek, TestRail gibi bağımsız araçlara kıyasla daha zahmetli 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 özelliği, 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 izlenebilmesi ve her hatanın onu tespit eden teste geri bağlanabilmesi gereken, tek bir Atlassian örneği içinde çalışan, düzenlemelere tabi veya sık denetime tabi takımlar (fintech, sağlık sektörü).
Şu durumlarda atlayın: Jira örneğiniz büyük ve QA takımınız küçükse. 10 test uzmanının bulunduğu 200 lisanslı bir Jira örneğinde, hiç kimse tarafından kullanılmayan 190 Zephyr lisansı için para ödüyorsunuz; test uzmanı başına fiyatlandırılan bağımsız bir araç daha ucuza mal olur.
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ılmaktadı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 gerçekleştirmek için Zephyr Scale veya Xray gibi çözümlerle birlikte Jira’yı kullanmaktadı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ğine ek olarak kullanıcı başına ayrı bir ücret gerektiren 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 yorum)
- 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üşleri:
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 özelliklerini 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ü kendi sınıfında 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 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 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
Test senaryolarının genel etkinliğini azaltabilecek bu yazım hatalarından kaçının.
| Hata | Bunun yerine yapılacak şey |
|---|---|
| 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, fonksiyonlarda 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 belirtin (test kullanıcısı silindi, sepet boşaltıldı, oturum kapalı), böylece bir sonraki senaryo temiz bir durumdan başlasın. |
| Yalnızca normal akış verileri | Her giriş alanının, sistem tarafından reddedilmesi gereken en az bir değer içermesi 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 senaryonun 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ı yakalayan 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ığı "off-by-one" hatalarını bulur.
Yinelenen senaryoları azaltmak için eşdeğerlik bölümlemesini kullanı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. kullanıcı@example.com, jane@company.com ve bob@domain.org adreslerini üç ayrı test senaryosu olarak test etmek, kapsama alanını genişletmeden bakım yükünüzü üç katına çıkarır.
Test verilerini test adımlarından ayırın
Bir adıma “enter test@example.com” 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ümesine geçmek tek satırlık bir değişiklikle halledilebilir.
Kararsız testleri ve kaçan hata 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, sadece gürültülü olan yerleri değil, kapsama alanının zayıf olduğu yerleri de belirleyin.
En sık çalıştırdığınız testleri otomasyonla otomatikleştirin
Regresyon, smoke 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şamada kullanıldığını ele almaktadır. Bu bölümde ise kılavuzun önceki bölümlerinde anlatılan adımlara göre 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, Ödemeler, 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 ID, ön koşullar, test verileri, öncelik seviyesi 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 idealdir; açıklama kısmı 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örevi, bağlantılı spesifikasyonları ve yorumları okur, düzeltmeyi yazar ve ilerleme durumu göreve geri gönderilen bir çekme talebi açar.
Profesyonel İpucu: Kalite güvencesi (QA) liderleri, ClickUp Brain'den açık hata görevlerini özetlemesini isteyerek herhangi bir görevin anlık durumunu görebilir. Böylelikle, resmin bütününü anlamak için tek tek görevleri incelemek zorunda kalmadan, sprint incelemeleri için ihtiyaç duydukları tüm bağlam bilgisine sahip olurlar.
Test döngülerini görünümlerle çalıştırın. Test çalışması 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. Düzinelerce 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 filtreleyin veya öncelik sırasına göre filtreleyerek kritik yollara öncelik vererek hızlı test 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ça Sorulan Sorular
Bir gereksinimin kaç test senaryosu olması gerekir?
Tek bir gereksinim, içerdiği senaryo, uç durum ve girdi varyasyonlarının sayısına bağlı olarak bir test senaryosu ya da on test senaryosu gerektirebilir. Buradaki amaç, tüm gerçekçi yolları kapsayarak, gereksiz tekrarlar olmadan yeterli kapsam sağlamak.
Test senaryoları ile test komut dosyaları arasındaki fark nedir?
Bir test senaryosu, neyin test edileceğini ve ne tür bir sonuç beklendiğini belgeleyen, manuel olarak yürütülmek üzere yazılmış bir belgedir. 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 herhangi bir bağlam bilgisi olmadan da kolayca takip edilebilecek 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. Önce senaryolar gelir ve kapsam planlamasını yönlendirir; ardından test senaryoları 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 girildiğinde 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 yönetmesini bekler: yanlış şifre girildiğinde, oturum açılmadan “Geçersiz şifre” mesajı görüntülenir. Olgun test takımlarında olumlu ve olumsuz test senaryolarının oranı yaklaşık 1:3 ile 1:5 arasındadır; çünkü üretim ortamındaki hataların çoğu, normal işleyiş senaryolarında değil, hata senaryolarında ortaya çıkar.
Bir test planı, tüm test çabasının kapsamını, yaklaşımını, kaynaklarını ve zaman çizelgesini 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 sonucu olan, belgelenmiş bir kontrol. Plan stratejiyi belirler, paket kapsamı belirler, senaryo ise sonucu belirler.