test scenario vs test case
Test Senaryosu ile Test Vakası Arasındaki Fark.
6 yıl önce , orta ölçekli bir ÇUŞ ile çalışırken, test senaryoları adı verilen tam kanıt belgesini hazırlamak için zaman kaybetmektense, test senaryolarını belgelemeyi önerdiğimde, tüm kafalar canımı sıkıyor.
Yüzlerdeki ifade, önermekle büyük bir hata yaptığımı açıkça ifade ediyordu. Kimse inkar etse de kimse kabul etmedi. Herkes geleneği takip etmenin, yani test vakası belgeleri yazmanın daha güvenli olacağını hissetti. Ben tartışamadım.
4 yıl sonra , şirket, tek kısıtlamanın zaman olduğu ve tek beklentinin tam kanıt olduğu bir test projesi aldı test yapmak.
Tekrar toplantıdaydık ve kritik son teslim tarihine yetişmek için fikirleri tartışıyorduk. Uygulama, temel olarak farklı menü öğeleri aracılığıyla farklı raporlar aramak ve oluşturmakla ilgiliydi. Test vakalarını belgelemenin çoğu zaman yakalanması gerekiyordu ve belgenin müşteri için ne kadar kullanılacağından emin değildik.
Test senaryolarını belgelemeyi önerdim ve bir şekilde biraz tereddüt ederek herkes kabul etti. Değerli dokümantasyon süresinden tasarruf edebileceğimizi ve bunu test için kullanabileceğimizi belirtmeye gerek yok.
Ne öğreneceksin:
- Test Durumları Test Senaryolarıyla Hızlı Bir Şekilde Değiştiriliyor mu?
- Test Durumlarının Belgelendirilmesi Ne Zaman Önemlidir?
- Tablo Biçiminde Test Senaryosu ile Test Durumu Arasındaki Farklar
- Sonuç
- Önerilen Kaynaklar
Test Durumları Test Senaryolarıyla Hızlı Bir Şekilde Değiştiriliyor mu?
Zamanla her şey değiştikçe yazılım sektörü ve süreçleri de çok değişti.
bilgisayarda swf dosyaları nasıl görüntülenir
Geleneksel Şelale ve V modelleri yerini çevik ve yinelemeli modeller alıyor. Dokümantasyon gerekli ancak son teslim tarihlerini karşılamak ve süreci kolay ve şeffaf hale getirmek için, dokümantasyon yöntemi değiştirilebilir.
Test Durumlarının Belgelendirilmesi Ne Zaman Önemlidir?
- Müşteri, projenin bir parçası olarak aynı şeyi istedi.
- Zaman kısıtlaması yok (bunun mümkün olduğunu sanmıyorum).
- Test cihazları daha taze veya ürüne bilinmiyor.
- Şirket politikası (Değiştirilebileceğine şiddetle inanıyorum).
Sizinle bir deneyimi paylaşmama izin verin:
Ekibimle birlikte, esnek zaman çizelgelerine sahip bir Fortune 500 şirketinden bir projenin test edilmesine katıldık. Test senaryolarını mevcut en iyi şablonla belgeledik ve müşteri tarafından onaylattık.
Yapı QA ekibine yayınlanmaya başladığında, günün büyük bölümünde görevimiz, günde 100 test vakasını mekanik olarak takip etmek, belgeyi geçti / kaldı sonucu ile güncellemek ve günün sonunda müşteriye göndermekti. Çoğu takım üyeleri şikayet etmeye başladı monoton çalışma ancak şirket gelir elde ediyordu.
Sonra test edilecek yeni bir yapı olmadan arada bir gün ara verildi. Günün başında birlikte oturduk ve o gün ne yapacağımızı tartışıyorduk. Test senaryosu belgesini iyileştirmek için daha fazla fikir üretmeyi önerdiğimde, tüm ekip üyeleri çaba göstermeyi reddetti.
Onlara göre, tüm senaryoları ele aldığımız için düşünecek başka bir şey yoktu. Ve onları ikna etmek kutunun dışında düşünün ve daha fazla fikir üretin gerçekten zordu.
Çoğu zaman, test vakalarını belgelediğimizde ve bu da müşteri tarafından onaylandıktan sonra, insan zihninin işimizi yaptığımızı düşündüğünü ve zihnimiz, ürünü test etmenin başka yollarını düşünme çabasını otomatik olarak durdurur.
Ve inan bana, test senaryoları dokümanı hazırlandığında, sadece mekanik olarak takip etmek istiyoruz. Bana kariyerinizde kaç kez sizin veya takım arkadaşınızın onaylanmış test senaryoları belgesine ek test senaryoları sunduğunu deneyimlediğinizi söyleyin?
Bir deneyim daha:
Haftalık ekip mücadelesi etkinliği sırasında, uygulamayı duyurduk ve ekip üyelerinden test senaryolarını doldurmalarını istedik.
Geç yanıt verenler veya yanıt vermeyenler dahil olmak üzere tüm ekip üyeleri fikirlerini ortaya koydu. Neden? Her bir işlevsellik dizisi ve her test senaryosu için ön koşul için beklenen sonucu doldurmaları gereken resmi bir belge yoktu. Bir günde 40 test senaryosu topladık ve bu harika bir deneyimdi.
Deneyimimi desteklemek için Bir örnek sunmak istiyorum.
Örnek bir uygulama alın, kullanıcı adı, şifre, giriş ve iptal düğmelerinin bulunduğu giriş sayfası deyin. Aynı test senaryoları yazmamız istenirse, farklı seçenekleri ve ayrıntıları birleştirerek 50'den fazla test senaryosu yazacağız.
Ancak test senaryoları yazılacaksa aşağıdaki gibi 10 satırlık bir mesele olacaktır:
Üst Düzey Senaryo: Oturum Açma İşlevselliği
Düşük Seviye Senaryolar :
1. Uygulamanın Başlatılmakta olduğunu kontrol etmek için
2. Giriş sayfasındaki metin içeriğini kontrol etmek için
3. Kullanıcı adı alanını kontrol etmek için
4. Parola alanını kontrol etmek için
5. Oturum Açma Düğmesini kontrol etmek ve düğme işlevini iptal etmek için
Ayrıca bakınız=> Web ve masaüstü uygulamalarını test etmek için 180'den fazla Örnek Test senaryosu.
Hepimizin zamanı kısıtlı olduğu için, test senaryoları eski IODEX'ten ziyade ağrı kesici sprey olarak çalışır. Ve yine de etkisi aynı.
Tablo Biçiminde Test Senaryosu ile Test Durumu Arasındaki Farklar
Son olarak, Test Senaryosu ile Test Vakası arasındaki farkı özetlemek isterim:
warcraft özel sunucusunun en iyi dünyası
Test Durumları | Test Senaryoları | |
---|---|---|
Nedir => | Neyin test edileceğini, atılması gereken adımların ve aynı sonucun beklenen sonucunun ayrıntılı bilgi veren bir kavram | Neyin test edileceğine dair tek satırlık bilgi sağlayan bir kavram. |
Konu => | Daha çok ayrıntıları belgelemekle ilgili. | Daha çok düşünmek ve ayrıntıları tartışmakla ilgilidir. |
Önem => | Testler kapalı olduğunda ve geliştirme yerinde olduğunda önemlidir. Ayrıntılarla birlikte test senaryoları yazmak, hem geliştirici hem de QA ekibinin senkronize olmasına yardımcı olacaktır. | Zamanın az olduğu ve ekip üyelerinin çoğu tek satırlık senaryodaki ayrıntıları kabul edebildiği / anlayabildiği zaman önemlidir. |
Avantaj => | Tüm test senaryolarının tek seferlik dokümantasyonu, gelecekte 1000'lerdeki regresyon testini izlemek için faydalıdır. Çoğu zaman, hata bildirimi sırasında faydalıdır. Test uzmanının sadece test senaryosu kimliğine referans vermesi gerekir ve her dakika detayından bahsetmeyi gerektirmez. | Yeni nesil yazılım test topluluğu tarafından tercih edilen, zaman kazandıran ve fikir üretme etkinliği. Değişiklik ve ekleme basittir ve kişiye özel değildir. Bir grup insanın yalnızca belirli modülleri bildiği büyük bir proje için, bu aktivite herkese diğer modülleri ve beyin fırtınasını inceleme ve tartışma şansı verir. |
Faydalı => | Tam dayanıklı bir test durumu belgesi, yeni test uzmanı için bir yaşam çizgisidir. | İyi bir test kapsamı, uygulamayı test senaryolarına bölerek elde edilebilir ve bu, ürünün tekrarlanabilirliğini ve karmaşıklığını azaltır. |
Dezavantaj => | Neyin test edileceği ve nasıl test edileceği hakkında her şeyi detaylandırmak için daha fazla kaynak gerektirdiğinden zaman ve para tüketir | Belirli bir kişi tarafından oluşturulmuşsa, gözden geçiren veya diğer kullanıcı, arkasındaki fikri tam olarak senkronize etmeyebilir. Daha fazla tartışmaya ve ekip çabasına ihtiyacınız var. |
Sonuç
Test senaryoları, Yazılım Geliştirme Yaşam Döngüsünün en önemli parçasıdır ve biri olmadan bir şeyi izlemek, anlamak, takip etmek ve gerekçelendirmek zordur. Ancak Agile çağında, test senaryolarının yerini hızla test senaryoları alıyor.
Ortak test kontrol listesi Her test türü için (Veritabanı testi, GUI testi, İşlevsellik testi, vb.) test senaryoları ile birlikte Yazılım Test Cihazları için modern bir topçudur. Tartışmalar, eğitimler, sorular ve pratik, kesinlikle son grafiğini değiştirebilir. üretkenliğiniz yanı sıra bir Hata raporu matrisi.
Her zaman olduğu gibi, düşüncelerinizi ve sorularınızı memnuniyetle karşılıyoruz. Lütfen izleyin.
PREV Eğitimi | SONRAKİ Eğitici
Önerilen Kaynaklar
- Test Planı, Test Stratejisi, Test Senaryosu, Test Komut Dosyası, Test Senaryosu ve Test Koşulu Arasındaki Fark
- Yazılım Testi Türleri: Ayrıntılarla Birlikte Farklı Test Türleri
- Test Örnekleri Nasıl Yazılır: Örneklerle Son Kılavuz
- SRS Belgesi Nasıl Gözden Geçirilir ve Test Senaryoları Oluşturulur - Canlı Bir Projede Yazılım Test Eğitimi - 2. Gün
- Pozitif ve Negatif Test Senaryoları Nasıl Sınıflandırılır - Bir Test Uzmanının Hile Sayfası
- Performans Testi - Yük Testi - Stres Testi (Fark)
- Statik Test ve Dinamik Test - Bu İki Önemli Test Tekniği Arasındaki Fark
- Yazılım Testinin Temelleri Arasındaki 101 Fark