Test Örnekleri Nasıl Yazılır: Örneklerle Son Kılavuz

how write test cases

Test Vakalarının Nasıl Yazılacağı hakkındaki bu derinlemesine uygulamalı öğreticide, Test Vakasının ne olduğu, standart tanımı ve Test Vaka Tasarımı tekniklerinin ayrıntılarını ele aldım.

Test senaryosu nedir?

Bir test senaryosu, bir uygulamanın bir özelliğinin doğru çalışıp çalışmadığını belirlemek için girişi, eylemi ve beklenen yanıtı tanımlayan bileşenlere sahiptir.

Bir test senaryosu, belirli bir test hedefini / hedefini doğrulamak için 'NASIL' üzerine bir talimatlar dizisidir ve takip edildiğinde sistemin beklenen davranışının karşılanıp karşılanmadığını bize söyler.

Bu Test Vakası Yazma Serisinde Kapsanan Öğreticilerin Listesi:

Nasıl yazılır:

Öğretici 1: Test Vakası Nedir ve Test Vakaları Nasıl Yazılır? (bu eğitim)
Öğretici # 2: Örneklerle Örnek Test Vaka Şablonu (İndir) (okunmalı)
Öğretici 3: SRS Belgesinden Test Örnekleri Yazma
Eğitim 4: Verilen Bir Senaryo İçin Test Durumları Nasıl Yazılır
Öğretici 5: Kendinizi Test Vakası Yazmaya Nasıl Hazırlayabilirsiniz?
Öğretici # 6: Negatif Test Durumları Nasıl Yazılır

Örnekler:

Eğitim 7: Web ve Masaüstü Uygulamaları için 180+ Örnek Test Durumu
Eğitim # 8: 100+ Yürütülmeye Hazır Test Senaryosu (Kontrol Listesi)

Yazım Teknikleri:

Eğitim 9: Neden ve Sonuç Grafiği - Dinamik Test Vakası Yazma Tekniği
Öğretici # 10: Durum Geçiş Testi Tekniği
Öğretici # 11: Ortogonal Dizi Test Tekniği
Eğitim # 12: Hata Tahmin Tekniği
Eğitim # 13: Alan Doğrulama Tablosu (FVT) Test Tasarım Tekniği

Test Case Vs Test Senaryoları:

Eğitim # 14: Test Örnekleri ve Test Senaryoları
Öğretici # 15: Test Planı, Test Stratejisi ve Test Senaryosu Arasındaki Fark

Otomasyon:

Öğretici # 16: Otomasyon Testi İçin Doğru Test Durumları Nasıl Seçilir
Öğretici # 17: Manuel Test Durumlarını Otomasyon Komut Dosyalarına Çevirme

Test Yönetim Araçları:

Eğitim # 18: En İyi Test Yönetim Araçları
Eğitim # 19: Test senaryosu yönetimi için TestLink
Eğitim 20: HP Kalite Merkezini Kullanarak Test Durumları Oluşturma ve Yönetme
Öğretici # 21: ALM / QC Kullanarak Test Durumlarını Yürütme

Alana Özgü Durumlar:

Eğitim # 22: ERP Uygulaması için Test Durumları
Eğitim # 23: JAVA Uygulama test durumları
Eğitim 24: Sınır değer analizi ve Eşdeğer bölümleme

Bu serideki ilk eğiticiye devam edelim.

Önerilen Araçlar:

Test senaryosu yazma sürecine devam etmeden önce, bu test senaryosu yönetim aracını indirmenizi öneririz. Bu, bu eğiticide bahsedilen test senaryoları yazma sürecinizi kolaylaştıracaktır:

# 1) TestRail

=> TestRail Test Case Management Tool'u İndirin

# 2) TestMonitor

Üst düzey çevrimiçi Test Yönetimi. Devrim niteliğinde kolay.

TestMonitor, her kuruluş için uçtan uca bir test yönetim aracıdır. Test etmeye basit, sezgisel bir yaklaşım. İster kurumsal yazılım uyguluyor, ister kalite kontrolüne, kaliteli bir uygulama oluşturmaya veya sadece test projenizde bir yardım eline ihtiyaç duyuyor olun, TestMonitor size yardımcı olacaktır.

=> TestMonitor Web Sitesini ziyaret edin

Ne öğreneceksin:

• Test Vakası Nedir ve Test Vakası Nasıl Yazılır?
  • Neden Testler Yazıyoruz?
  • Test Durumları Nasıl Yazılır?
  • Temel Test Durumu Bildirimi Formatı
• Test Yazma İpuçları
  • • # 1) Basit tutun ama çok basit değil; karmaşık hale getirin, ancak çok karmaşık değil:
    • # 2) Test senaryolarını belgeledikten sonra, Testçi olarak bir kez inceleyin:
    • # 3) Sınırlı ve Test Kullanıcılarını kolaylaştırın:
    • # 4) Katkıda Bulunan Olun:
    • # 5) Son Kullanıcıyı Asla Unutma:
• Test Vakası Dokümantasyonunda Mükemmelliğe Nasıl Ulaşılır
  • Yararlı İpuçları ve Püf Noktaları
    • # 1) Test Belgeniz İyi Durumda mı?
    • # 2) Olumsuz Durumları Örtmeyi Unutmayın
    • # 3) Atomik Test Adımlarına Sahip Olun
    • # 4) Testlere Öncelik Verin
    • # 5) Sıra Önemlidir
    • # 6) Yorumlara Zaman Damgası ve Test Kullanıcısının Adını Ekleyin
    • # 7) Tarayıcı Ayrıntılarını Ekleyin
    • # 8) İki ayrı sayfa tutun - Belgedeki 'Hatalar' ve 'Özet'
• Testler Nasıl Yazılamaz
  • Test Durumlarında En Sık Karşılaşılan 3 Sorun
    • # 1) Kompozit Adımlar
    • # 2) Uygulama davranışı, beklenen davranış olarak alınır
    • # 3) Bir durumda Birden Çok Koşul
• Test Senaryosu Verimliliği Nasıl Artırılır
  • Sınav Yazımı için Belge Toplama
  • Gerçek Örnek
  • Test Durumu Belgesi
  • Test Verisi Toplama
• Test Durumlarını Standartlaştırmanın Önemi
  • Test Durumlarını Yeniden Kullanmanın Nedenleri
  • Web Testinde Standart Test Nedir?
  • Sonuç
  • Önerilen Kaynaklar

Test Vakası Nedir ve Test Vakası Nasıl Yazılır?

Etkili vakalar yazmak bir beceridir. Ve test edilen uygulamanın deneyiminden ve bilgisinden öğrenebilirsiniz.

Testlerin nasıl yazılacağına ilişkin temel talimatlar için lütfen aşağıdaki videoyu kontrol edin:

Yukarıdaki kaynaklar bize test yazma sürecinin temellerini vermelidir.

Test yazma sürecinin seviyeleri:

• Seviye 1: Bu seviyede, mevcut spesifikasyondaki temel durumlar ve kullanıcı belgeleri.
• Seviye 2: Bu pratik aşama Yazma vakalarının, uygulamanın gerçek işlevselliğine ve sistem akışına bağlı olduğu.
• 3. seviye: Bu, bazı vakaları gruplayacağınız aşamadır ve bir test prosedürü yaz . Test prosedürü, bir grup küçük vakadan başka bir şey değildir, belki maksimum 10 olabilir.
• Seviye 4: Projenin otomasyonu. Bu, sistemle insan etkileşimini en aza indirecek ve böylece QA, Regresyon testiyle meşgul olmak yerine test etmek için şu anda güncellenen işlevlere odaklanabilir.

Neden Testler Yazıyoruz?

Vaka yazmanın temel amacı bir uygulamanın test kapsamını doğrulamak için.

Herhangi bir CMMi organizasyonunda çalışıyorsanız, test standartları daha yakından takip edilir. Vakaların yazılması bir tür standardizasyon getirir ve testte geçici yaklaşımı en aza indirir.

Test Durumları Nasıl Yazılır?

Alanlar:

• Test durumu kimliği
• Test edilecek birim: Ne doğrulanmalı?
• Varsayımlar
• Test verisi: Değişkenler ve değerleri
• Yürütülecek adımlar
• Beklenen Sonuç
• Gerçek sonuç
• Başarılı / Başarısız
• Yorumlar

Temel Test Durumu Bildirimi Formatı

Doğrulayın
Kullanma (araç adı, etiket adı, iletişim kutusu vb.)
İle (koşullar)
İçin (döndürülen, gösterilen, gösterilen)

Doğrulayın: Test ifadesinin ilk kelimesi olarak kullanılır.
Kullanarak: Neyin test edildiğini belirlemek için. Duruma bağlı olarak kullanmak yerine burada 'girmeyi' veya 'seçmeyi' kullanabilirsiniz.

Herhangi bir uygulama için, aşağıdaki gibi her tür testi kapsamanız gerekir:

• Fonksiyonel durumlar
• Olumsuz durumlar
• Sınır değer durumları

Bunların hepsini yazarken En Çok Katkıda Bulunanlar basit ve anlaşılması kolay olmalıdır .

*************************************************

Test Yazma İpuçları

Bir Yazılım Test Cihazının (SQA / SQC personeli) en sık ve en önemli faaliyetlerinden biri Test senaryoları ve vakaları yazmaktır.

Bu büyük faaliyetle ilgili bazı önemli ve kritik faktörler vardır. Önce bu faktörlere kuş bakışı bakalım.

Yazma Sürecini İçeren Önemli Faktörler:

a) En Çok Katkıda Bulunanlar düzenli revizyon ve güncellemeye yatkındır:

Sürekli değişen bir dünyada yaşıyoruz ve aynı şey yazılım için de geçerli. Yazılım gereksinimleri değişikliği vakaları doğrudan etkiler. Gereksinimler değiştirildiğinde TC'lerin güncellenmesi gerekir.

Yine de, TC'lerin revizyonuna ve güncellenmesine neden olabilecek sadece gereksinimdeki değişiklik değildir. TC'lerin yürütülmesi sırasında akılda birçok fikir ortaya çıkar ve tek bir TC'nin birçok alt koşulu belirlenebilir. Tüm bunlar TC'lerin güncellenmesine ve hatta bazen yeni TC'lerin eklenmesine yol açar.

Ayrıca, regresyon testi sırasında, çeşitli düzeltmeler ve / veya dalgalanmalar revize edilmiş veya yeni TC'ler gerektirir.

b) TC'ler, bunları uygulayacak olan test uzmanları arasında dağıtılmaya eğilimlidir:

Elbette, tek bir test uzmanının tüm TC'leri yürüttüğü hemen hemen böyle bir durum yoktur. Normalde, tek bir uygulamanın farklı modüllerini test eden birkaç test görevlisi vardır. Böylece TC'ler, test edilen uygulamanın sahip oldukları alanlara göre test uzmanları arasında bölünür.

Uygulamanın entegrasyonu ile ilgili bazı TC'ler birden fazla test görevlisi tarafından yürütülebilirken, diğer TC'ler yalnızca tek bir test cihazı tarafından yürütülebilir.

c) TC'ler Kümeleme ve Gruplamaya eğilimlidir:

Tek bir test senaryosuna ait TC'lerin genellikle belirli bir sırayla veya bir grup şeklinde uygulanmasını talep etmesi normal ve yaygındır. Bir TC'nin, kendisini yönetmeden önce diğer TC'lerin infazını talep eden belirli ön koşulları olabilir.

Benzer şekilde, AUT'nin iş mantığına göre, tek bir TC, birkaç test koşullarına katkıda bulunabilir ve tek bir test koşulu, birden fazla TC'den oluşabilir.

d) TC'lerin birbirine bağımlı olma eğilimi vardır:

Bu aynı zamanda TC'lerin birbirlerine bağımlı olabileceklerini belirten ilginç ve önemli bir davranışıdır. Karmaşık iş mantığına sahip orta ve büyük uygulamalarda bu eğilim daha belirgindir.

Bu davranışın kesinlikle gözlemlenebildiği herhangi bir uygulamanın en net alanı, aynı veya hatta farklı uygulamaların farklı modülleri arasındaki birlikte çalışabilirliktir. Basitçe söylemek gerekirse, farklı modüllerin tek bir uygulamanın veya birden çok uygulamanın birbirine bağlı olduğu her yerde, aynı davranış TC'lere de yansıtılır.

e) TC'ler geliştiriciler arasında dağıtılmaya eğilimlidir (özellikle Test odaklı geliştirme ortamında):

En Çok Katkıda Bulunanlar hakkında önemli bir gerçek, bunların yalnızca test uzmanları tarafından kullanılmamasıdır. Normal durumda, geliştiriciler tarafından bir hata düzeltildiğinde, sorunu gidermek için dolaylı olarak TC'yi kullanırlar. Benzer şekilde, test odaklı geliştirme takip edilirse, TC'ler, mantıklarını oluşturmak ve TC'ler tarafından ele alınan kodlarındaki tüm senaryoları kapsamak için geliştiriciler tarafından doğrudan kullanılır.

Etkili Testler Yazmanın İpuçları:

Yukarıdaki 5 faktörü göz önünde bulundurarak, İşte etkili TC'ler yazmak için birkaç ipucu.

Hadi başlayalım!!!

# 1) Basit tutun ama çok basit değil; karmaşık hale getirin, ancak çok karmaşık değil:

Bu ifade bir paradoks gibi görünüyor. Ama söz veriyorum öyle değil. TC'lerin tüm adımlarını atomik ve kesin tutun. Doğru sırayla adımlardan bahsedin ve beklenen sonuçlarla doğru eşleştirme yapın. Test senaryosu, kendinden açıklamalı ve anlaşılması kolay olmalıdır. Bunu basitleştirmek için kastettiğim bu.

Şimdi, onu Test Planı ve diğer TC'ler ile entegre etmek için karmaşık bir araç haline getirmek. Gerektiğinde diğer TC'lere, ilgili yapılara, GUI'lere vb. Başvurun. Ancak bunu dengeli bir şekilde yapın. Tek bir test senaryosunu tamamlamak için bir test uzmanı belge yığınında gidip gelmeyin.

Öte yandan, test uzmanının bu TC'leri çok kompakt bir şekilde belgelemesine bile izin vermeyin. En Çok Katkıda Bulunanlar yazarken, her zaman sizin veya başka birinin bunları gözden geçirip güncellemesi gerektiğini unutmayın.

# 2) Test senaryolarını belgeledikten sonra, Testçi olarak bir kez inceleyin:

Test senaryosunun son TC'sini yazdıktan sonra işin bittiğini asla düşünmeyin. Başa gidin ve tüm TC'leri bir kez inceleyin, ancak bir TC yazarının veya Test Planlamacısının zihniyetiyle değil. Bir testçinin zihninde tüm TC'leri inceleyin. Mantıklı düşünün ve TC'lerinizi kuru çalıştırmaya çalışın.

Tüm Adımları değerlendirin ve bunları anlaşılır bir şekilde açıkça ifade edip etmediğinizi ve beklenen sonuçların bu adımlarla uyumlu olup olmadığını görün.

Emin olun test verisi TC'lerde belirtilenler yalnızca gerçek test uzmanları için değil, aynı zamanda gerçek zamanlı ortama da uygundur. En Çok Katkıda Bulunanlar arasında bir bağımlılık çatışması olmadığından emin olun ve diğer TC'lere / yapılara / GUI'lere yapılan tüm referansların doğru olduğunu doğrulayın. Aksi takdirde, Testçilerin başı büyük belada olabilir.

# 3) Sınırlı ve Test Kullanıcılarını kolaylaştırın:

Test verilerini test cihazlarında bırakmayın. Özellikle hesaplamaların yapılacağı veya uygulamanın davranışının girdilere bağlı olduğu yerlerde onlara bir dizi girdi verin. Test verisi öğelerinin değerlerine karar vermelerine izin verebilir, ancak onlara asla test verisi öğelerini kendileri seçme özgürlüğü vermeyin.

Çünkü kasıtlı veya kasıtsız olarak aynı test verilerini tekrar tekrar kullanabilirler ve TC'lerin yürütülmesi sırasında bazı önemli test verileri göz ardı edilebilir.

TC'leri test kategorilerine ve bir uygulamanın ilgili alanlarına göre düzenleyerek test kullanıcılarını rahat ettirin. Açık bir şekilde, hangi TC'lerin birbirine bağımlı ve / veya gruplandırıldığını açıklayın ve belirtin. Benzer şekilde, test edenin genel aktivitesini buna göre yönetebilmesi için hangi TC'lerin bağımsız ve izole olduğunu açıkça belirtin.

Bu noktada, kara kutu testinde kullanılan bir test senaryosu tasarım stratejisi olan sınır değer analizi hakkında bilgi almak isteyebilirsiniz. Tıklayın İşte hakkında daha fazla bilgi edinmek için.

# 4) Katkıda Bulunan Olun:

FS veya Tasarım Belgesini asla olduğu gibi kabul etmeyin. İşiniz sadece FS'yi gözden geçirmek ve Test Senaryolarını belirlemek değildir. Bir QA kaynağı olarak, uygulamada bir şeylerin geliştirilebileceğini düşünüyorsanız, işletmeye katkıda bulunmaktan ve önerilerde bulunmaktan asla çekinmeyin.

Özellikle TC güdümlü geliştirme ortamında geliştiricilere de önerin. Açılır listeleri, takvim kontrollerini, seçim listesini, grup radyo düğmelerini, daha anlamlı mesajları, uyarıları, uyarıları, kullanılabilirlikle ilgili iyileştirmeleri vb. Önerin.

Kalite Güvencesi olmak, sadece test etmekle kalmayın, fark yaratın!

# 5) Son Kullanıcıyı Asla Unutma:

En önemli paydaş, uygulamayı nihayet kullanacak olan 'Son Kullanıcı' dır. Bu nedenle, TC'lerin yazımının hiçbir aşamasında onu asla unutma. Aslında, Son Kullanıcı, SDLC'nin hiçbir aşamasında göz ardı edilmemelidir. Yine de şimdiye kadar yaptığım vurgu sadece konu ile ilgili.

Bu nedenle, test senaryolarının tanımlanması sırasında, daha az sıklıkla kullanılsalar bile, kullanıcı tarafından çoğunlukla kullanılacak olan durumları veya iş açısından kritik olan durumları asla gözden kaçırmayın. Kendinizi Son Kullanıcının yerine koyun ve ardından tüm En Çok Katkıda Bulunanların üzerinden geçin ve belgelenmiş tüm TC'lerinizi yürütmenin pratik değerini değerlendirin.

*************************************************

Test Vakası Dokümantasyonunda Mükemmelliğe Nasıl Ulaşılır

Bir yazılım testçisi olarak, mükemmel bir Test Belgesi bulmanın gerçekten zor bir iş olduğu konusunda kesinlikle benimle hemfikir olacaksınız.

Her zaman iyileştirme için bir alan bırakırız. Test Vakası Belgeleri . Bazen, TC'ler aracılığıyla% 100 test kapsamı sağlayamıyoruz ve bazen test şablonu eşit değil veya testlerimize iyi okunabilirlik ve netlik sağlayamıyoruz.

Bir test uzmanı olarak, ne zaman test dokümantasyonu yazmanız istendiğinde, sadece plansız bir şekilde başlamayın. Dokümantasyon süreci üzerinde çalışmaya başlamadan önce test senaryoları yazmanın amacını iyi anlamak çok önemlidir.

Testler her zaman net ve anlaşılır olmalıdır. Testlerin her birinde tanımlanan adımları izleyerek, test uzmanına eksiksiz testi gerçekleştirme kolaylığı sağlayacak şekilde yazılmalıdır.

Ek olarak, test senaryosu belgesinin eksiksiz olması için gerektiği kadar vaka içermesi gerekir. test kapsamı . Örneğin , yazılım uygulamanızda meydana gelebilecek tüm olası senaryolar için testleri kapsamaya çalışmalısınız.

Yukarıdaki noktaları akılda tutarak, şimdi sizi Test Dokümantasyonunda Mükemmelliğe Nasıl Ulaşılır konulu bir tura götürmeme izin verin.

Yararlı İpuçları ve Püf Noktaları

Burada, size diğerlerinden test belgelerinizde size yardımcı olabilecek bazı yararlı yönergeler sunacağım.

# 1) Test Belgeniz İyi Durumda mı?

Test belgenizi düzenlemenin en iyi ve basit yolu, onu birçok tek yararlı bölüme ayırmaktır. Tüm testi birden çok test senaryosuna bölün. Ardından her senaryoyu birden çok teste bölün. Son olarak, her durumu birden çok test adımına bölün.

Excel kullanıyorsanız, her bir test senaryosunu çalışma kitabının ayrı bir sayfasında belgeleyin, burada her test senaryosu bir tam test akışını açıklar.

# 2) Olumsuz Durumları Örtmeyi Unutmayın

Bir yazılım testçisi olarak, alışılmışın dışında düşünmeniz ve uygulamanızın karşılaştığı tüm olasılıkları oluşturmanız gerekir. Test uzmanları olarak, yazılıma herhangi bir kimliksiz giriş teşebbüsü veya uygulamada herhangi bir geçersiz veri akışı durumunda durdurulmalı ve rapor edilmelidir.

Bu nedenle, olumsuz bir durum, olumlu bir durum kadar önemlidir. Sahip olduğunuz her senaryo için iki test durumu - bir pozitif ve bir negatif . Pozitif olan, amaçlanan veya normal akışı kapsamalıdır ve negatif olan, istenmeyen veya istisnai akışı kapsamalıdır.

# 3) Atomik Test Adımlarına Sahip Olun

Her test adımı atomik olmalıdır. Daha fazla alt adım olmamalıdır. Bir test adımı ne kadar basit ve anlaşılırsa, teste devam etmek o kadar kolay olur.

# 4) Testlere Öncelik Verin

Bir uygulamanın testini tamamlamak için genellikle sıkı zaman çizelgelerine sahibiz. Bu durumda, yazılımın bazı önemli işlevlerini ve yönlerini test etmeyi kaçırabiliriz. Bundan kaçınmak için, bunu belgelerken her testte bir öncelik etiketlemelisiniz.

Bir testin önceliğini tanımlamak için herhangi bir kodlamayı kullanabilirsiniz. 3 seviyeden herhangi birini kullanmak genellikle daha iyidir, yüksek, orta ve düşük veya 1, 50 ve 100. Bu nedenle, katı bir zaman çizelgeniz olduğunda, önce tüm yüksek öncelikli testleri tamamlamalı ve ardından orta ve düşük öncelikli testlere geçmelisiniz.

Örneğin - Bir alışveriş web sitesi için, uygulamaya geçersiz bir giriş girişimi için erişim reddinin doğrulanması yüksek öncelikli bir durum olabilir, ilgili ürünlerin kullanıcı ekranında görüntülendiğini doğrulamak orta öncelikli bir durum olabilir ve görüntülenen metnin rengini doğrulayabilir. ekran düğmeleri düşük öncelikli bir test olabilir.

# 5) Sıra Önemlidir

Testteki adımların sırasının kesinlikle doğru olup olmadığını kontrol edin. Yanlış bir adım dizisi kafa karışıklığına yol açabilir. Tercihen, adımlar, test edilmekte olan belirli bir senaryo için uygulamaya girişten uygulamadan çıkana kadar tüm sıralamayı tanımlamalıdır.

# 6) Yorumlara Zaman Damgası ve Test Kullanıcısının Adını Ekleyin

Bir uygulamayı test ettiğiniz, birisinin aynı uygulamaya paralel olarak değişiklik yaptığı veya testiniz tamamlandıktan sonra birisinin uygulamayı güncelleyebileceği bir durum olabilir. Bu, test sonuçlarınızın zamanla değişebileceği bir duruma yol açar.

Bu nedenle, bir test sonucunun (geçti veya kaldı) belirli bir zamandaki bir uygulamanın durumuna atfedilebilmesi için test yorumlarına testçinin adını içeren bir zaman damgası eklemek her zaman daha iyidir. Alternatif olarak, bir ' Yürütme Tarihi 'Sütunu, testin zaman damgasını açıkça tanımlayacak olan test senaryosuna ayrı olarak eklenir.

# 7) Tarayıcı Ayrıntılarını Ekleyin

Bildiğiniz gibi, bu bir web uygulamasıysa, test sonuçları testin yürütüldüğü tarayıcıya göre farklılık gösterebilir. Diğer test uzmanlarının, geliştiricilerin veya test belgesini inceleyenlerin kolaylığı için, sorunun kolayca kopyalanabilmesi için tarayıcı adını ve sürümünü vakaya eklemelisiniz.

# 8) İki ayrı sayfa tutun - Belgedeki 'Hatalar' ve 'Özet'

Bir excel'de belgelendirme yapıyorsanız, çalışma kitabının ilk iki sayfası Özet ve Hatalar olmalıdır. Özet sayfası test senaryosunu özetlemeli ve Hata sayfası test sırasında karşılaşılan tüm sorunları listelemelidir. Bu iki sayfayı eklemenin önemi, belgenin okuyucusuna / kullanıcısına testin net bir şekilde anlaşılmasını sağlamasıdır.

Bu nedenle, zaman kısıtlı olduğunda, bu iki sayfa teste genel bir bakış sağlamada çok yararlı olabilir.

Test dokümanı, mümkün olan en iyi test kapsamını, mükemmel okunabilirliği sağlamalı ve baştan sona tek bir standart formatı takip etmelidir.

Test dokümantasyonunun organizasyonu olarak sadece birkaç önemli ipucunu akılda tutarak, TC'lere öncelik vererek, bir TC'yi yürütmek için tüm zorunlu ayrıntılar da dahil olmak üzere her şeyi doğru sırada tutarak ve açık ve anlaşılır test adımları sağlayarak test dokümantasyonunda mükemmelliğe ulaşabiliriz. vb. yukarıda tartışıldığı gibi.

*************************************************

Testler Nasıl Yazılamaz

Zamanımızın çoğunu bunları yazmak, gözden geçirmek, yürütmek veya sürdürmekle geçiriyoruz. Testlerin aynı zamanda hataya en açık olanlar olması oldukça talihsiz bir durumdur. Anlama, organizasyon testi uygulamaları, zaman eksikliği vb.'deki farklılıklar, arzulanan çok şey bırakan testleri sıklıkla görmemizin nedenlerinden bazılarıdır.

Sitemizde bu konuda çok sayıda makale var ama burada göreceğiz Test senaryoları NASIL YAZILMAMALIDIR - ayırt edici, kaliteli ve etkili testler oluşturmada yardımcı olacak birkaç ipucu.

Okumaya devam edelim ve lütfen bu ipuçlarının hem yeni hem de deneyimli test kullanıcıları için olduğunu unutmayın.

Test Durumlarında En Sık Karşılaşılan 3 Sorun

1. Bileşik adımlar
2. Uygulama davranışı, beklenen davranış olarak alınır
3. Bir durumda birden çok koşul

Bu üçü, sınava yazma sürecindeki en yaygın 3 sorun listemde olmalı.

İlginç olan, bunların hem yeni hem de deneyimli testçilerde gerçekleşmesidir ve biz sadece birkaç basit önlemin işleri kolayca düzeltebileceğini asla fark etmeden aynı kusurlu süreçleri izlemeye devam ediyoruz.

Hadi başlayalım ve her birini ayrıntılı olarak tartışalım:

# 1) Kompozit Adımlar

Her şeyden önce, bileşik adım nedir?

Örneğin, A noktasından B noktasına yön veriyorsunuz: 'XYZ yerine gidin ve sonra ABC'ye gidin' derseniz bu pek bir anlam ifade etmeyecek, çünkü burada kendimizi şöyle düşünürken buluyoruz - 'Nasıl yaparım? ilk etapta XYZ'ye gidin ”- bunun yerine' Buradan sola dönün ve 1 mil gidin, sonra Rd. XYZ'ye ulaşmak için hiçbir 11 'daha iyi sonuçlar elde edebilir.

Aynı kurallar testler ve testleri için de geçerlidir.

Örneğin Amazon.com için bir test yazıyorum - herhangi bir ürün için sipariş verin.

Aşağıdakiler benim test adımlarımdır (Not: Beklenen sonuç gibi testin diğer tüm bölümlerini değil, yalnızca adımları yazıyorum.)

-e . Amazon.com'u başlatın
b . Ekranın üst kısmındaki 'Ara' alanına ürün anahtar kelimesini / adını girerek bir ürün arayın.
c . Görüntülenen arama sonuçlarından ilkini seçin.
d . Ürün detayları sayfasındaki Sepete Ekle'ye tıklayın.
dır-dir . Ödeme ve ödeme.
f . Sipariş onay sayfasını kontrol edin.

Şimdi, bunlardan hangisinin bileşik bir adım olduğunu belirleyebilir misiniz? Sağ Adım (e)

Unutmayın, testler her zaman 'Nasıl test edilir' ile ilgilidir, bu nedenle testinizde 'Nasıl kontrol edilir ve ödeme yapılır' adımlarını tam olarak yazmanız önemlidir.

Bu nedenle yukarıdaki durum aşağıdaki gibi yazıldığında daha etkilidir:

-e . Amazon.com'u başlatın
b . Ekranın üst kısmındaki 'Ara' alanına ürün anahtar kelimesini / adını girerek bir ürün arayın.
c . Görüntülenen arama sonuçlarından ilkini seçin.
d . Ürün detayları sayfasındaki Sepete Ekle'ye tıklayın.
dır-dir . Alışveriş sepeti sayfasında Ödeme'ye tıklayın.
f . CC bilgilerini, nakliye ve fatura bilgilerini girin.
g . Ödeme'yi tıklayın.
h . Sipariş onay sayfasını kontrol edin.

Bu nedenle, birkaç ayrı adıma bölünebilen bir bileşik adımdır. Bir dahaki sefere testler yazdığımızda, hepimiz bu kısma dikkat edelim ve bunu sandığımızdan daha sık yaptığımız konusunda benimle aynı fikirde olacağınızdan eminim.

# 2) Uygulama davranışı, beklenen davranış olarak alınır

Bu günlerde daha fazla proje bu durumla uğraşmak zorunda.

Belgeleme eksikliği, aşırı programlama, hızlı geliştirme döngüleri, bizi testleri yazmak veya testin temelini oluşturmak için uygulamaya (daha eski bir sürüm veya benzeri) güvenmeye zorlayan birkaç nedendir. Her zaman olduğu gibi, bu kanıtlanmış kötü bir uygulamadır - her zaman gerçekten değil.

Açık fikirli olduğunuz ve “AUT'nin kusurlu olabileceği” beklentisini sürdürdüğünüz sürece zararsızdır. Sadece öyle olduğunu düşünmediğinizde işler kötü işliyor. Her zaman olduğu gibi, örneklerin konuşmasına izin vereceğiz.

Aşağıdaki test adımlarını yazdığınız / tasarladığınız sayfaysa:

Dava 1:

Test senaryosu adımlarım aşağıdaki gibiyse:

1. Alışveriş sitesini başlatın.
2. Nakliye ve iade seçeneğine tıklayın - Beklenen sonuç: 'Bilgilerinizi buraya koyun' ve 'Devam et' düğmesiyle gönderim ve iade sayfası görüntülenir.

O halde bu yanlıştır.

Durum 2:

1. Alışveriş sitesini başlatın.
2. Nakliye ve iade üzerine tıklayın.
3. Bu ekranda bulunan 'Sipariş numarasını girin' metin kutusuna sipariş numarasını girin.
4. Devam Et'i tıklayın - Beklenen sonuç: Siparişin sevkıyat ve iadelerle ilgili ayrıntıları görüntülenir.

Durum 2 daha iyi bir test örneğidir, çünkü referans uygulama yanlış davransa bile, onu yalnızca bir kılavuz olarak alırız, daha fazla araştırma yaparız ve beklenen doğru işlevselliğe göre beklenen davranışı yazarız.

Sonuç olarak: Referans olarak uygulama hızlı bir kısayoldur, ancak kendi tehlikeleri de vardır. Dikkatli ve eleştirel olduğumuz sürece harika sonuçlar verir.

# 3) Bir durumda Birden Çok Koşul

Bir kez daha öğrenelim Misal .

Aşağıdaki test adımlarına bir göz atın: Aşağıdakiler, bir oturum açma işlevi için tek bir test içindeki test adımlarıdır.

a. Geçerli ayrıntıları girin ve Gönder'i tıklayın.
b. Kullanıcı adı alanını boş bırakın. Gönder'i tıklayın.
c. Şifre alanını boş bırakın ve Gönder'i tıklayın.
d. Zaten oturum açmış bir kullanıcı adı / şifre seçin ve Gönder'i tıklayın.

4 farklı vaka olması gerekenler bir araya getirildi. Düşünüyor olabilirsiniz- Bunun nesi yanlış? Çok fazla belge kaydediyor ve 4'te ne yapabilirim, 1'de yapıyorum o kadar da iyi değil mi? Pek iyi değil. Nedenler?

Okumaya devam etmek:

• Ya koşullardan biri başarısız olursa - tüm testi 'başarısız' olarak işaretlemeliyiz. Tüm vakayı 'başarısız' olarak işaretlersek, bu 4 koşulun da çalışmadığı anlamına gelir ve bu gerçekten doğru değildir.
• Testlerin bir akışa sahip olması gerekir. Ön koşuldan 1. adıma ve tüm adımlardan. Bu durumu takip edersem, (a) adımında başarılı olursa, 'giriş' seçeneğinin artık kullanılamadığı sayfaya giriş yapacağım. Öyleyse (b) adımına geldiğimde - test eden kişi kullanıcı adını nereye girecek? Görüyorsunuz, akış bozuldu.

Bu nedenle modüler testler yazın . Kulağa çok iş gibi geliyor ama sizin için tek yapmanız gereken şeyleri ayırmak ve bizim için çalışmak için en iyi arkadaşlarımız Ctrl + C ve Ctrl + V'yi kullanmak. :)

*************************************************

jnlp dosyası nasıl çalıştırılır

Test Senaryosu Verimliliği Nasıl Artırılır

Yazılım test uzmanları, testlerini yazılım geliştirme yaşam döngüsünün erken aşamasından, en iyisi yazılım gereksinimleri aşamasında yazmalıdır.

Test yöneticisi veya bir QA yöneticisi, aşağıdaki listeye göre mümkün olan maksimum belgeleri toplamalı ve hazırlamalıdır.

Sınav Yazımı için Belge Toplama

# 1) Kullanıcı Gereksinimleri Belgesi

İş sürecini, kullanıcı profillerini, kullanıcı ortamını, diğer sistemlerle etkileşimi, mevcut sistemlerin değiştirilmesini, işlevsel gereksinimleri, işlevsel olmayan gereksinimleri, lisanslama ve kurulum gereksinimlerini, performans gereksinimlerini, güvenlik gereksinimlerini, kullanılabilirlik ve eşzamanlı gereksinimleri vb. Listeleyen bir belgedir. .,

# 2) İş Kullanım Örneği Belgesi

Bu belge, kullanım durumu iş perspektifinden fonksiyonel gereksinimlerin senaryosu. Bu belge iş aktörlerini (veya sistemi), hedefleri, ön koşulları, son koşulları, temel akışı, alternatif akışı, seçenekleri, gereksinimler altında sistemin her bir iş akışının istisnalarını kapsar.

# 3) İşlevsel Gereksinimler Belgesi

Bu belge, gereksinimler altında sistem için her özelliğin işlevsel gereksinimlerini ayrıntılı olarak açıklamaktadır.

Normalde, işlevsel gereksinimler belgesi, hem geliştirme hem de test ekibi için olduğu kadar, her yazılım geliştirme için en önemli belge olarak görülmesi gereken taahhüt edilen (bazen dondurulmuş) gereksinimler için müşteriler dahil proje paydaşları için ortak bir havuz görevi görür.

# 4) Yazılım Proje Planı (İsteğe Bağlı)

Projenin ayrıntılarını, hedeflerini, önceliklerini, kilometre taşlarını, faaliyetlerini, organizasyon yapısını, stratejisini, ilerleme izleme, risk analizi, varsayımları, bağımlılıkları, kısıtlamaları, eğitim gereksinimlerini, müşteri sorumluluklarını, proje programını vb. Açıklayan bir belge,

# 5) QA / Test Planı

Bu belge, kalite yönetim sistemi, dokümantasyon standartları, değişiklik kontrol mekanizması, kritik modüller ve işlevler, konfigürasyon yönetim sistemi, test planları, hata izleme, kabul kriterleri vb.

test planı belge, test edilecek özellikleri, test edilmeyecek özellikleri, test ekibi tahsislerini ve bunların arayüzlerini, kaynak gereksinimlerini, test programını, test yazımını, test kapsamını, test çıktılarını, test yürütme ön koşullarını, hata raporlama ve takibi tanımlamak için kullanılır. mekanizma, test ölçümleri vb.

Gerçek Örnek

Aşağıdaki şekle göre tanıdık ve basit bir 'Giriş' ekranı için nasıl verimli bir şekilde test senaryoları yazacağımızı görelim. test yaklaşımı daha fazla bilgi ve kritik özellik içeren karmaşık ekranlar için bile neredeyse aynı olacaktır.

# 1) Herhangi bir test senaryosu süreci için ilk yaklaşım, varsa yukarıdaki gibi bir ekran prototipi (veya tel çerçeveler) almak olacaktır. Bu, bazı işlevler için mevcut olmayabilir ve geliştirmenin önceki aşamalarında bir prototip tasarlamanın kritikliğine bağlıdır.

Ama eğer bir SRS (Yazılım Gereksinimleri Belirtimi) belgesi proje için mevcuttur, ekran prototiplerinin çoğu proje ekibi tarafından geliştirilmiştir. Bu tür bir ekran, test uzmanının işini basitleştirir ve testlerin verimliliğini artırır.

#iki) Sonra, fonksiyonel gereksinim özellikleri . Organizasyon sürecine bağlıdır, birden çok belgeden oluşan bir paket halinde mevcut olacaktır.

Öyleyse, vaka yazmak için en iyi belgeye karar verin; bu, bir kullanıcı gereksinim belgesi veya işlevsel gereksinim özellikleri (veya test ekibi tarafından rahatça anlaşılabiliyorsa bir SRS belgesi) olabilir ve bu, seçilenin eksiksiz bir işlevsel akışını sağlayacaktır. test edilecek özellik.

# 3) Ekran prototipi ve işlevsel spesifikasyonlar yerine getirildikten sonra, test uzmanı aşağıdaki yaklaşım ve kriterlerle vakaları yazmaya başlamalıdır.

• UI Testleri :Kullanıcı tarafından görülebilen kontroller / alanlar. Test edilecek özellik için statik kontrol ve dinamik kontroller mevcuttur. Örneğin, Yukarıdaki giriş ekranında, 'Kullanıcı Adı ve Şifre' metinleri, yalnızca metni görüntülemek için hiçbir kullanıcı etkileşimi gerektirmeyen statik alanlardır.

• Fonksiyonel Durumlar :Öte yandan, Oturum Aç düğmesi ve Köprüler (Parolanızı mı unuttunuz? & Kayıt), kontrollere tıklayarak kullanıcı etkileşimi gerektiren ve daha sonra bazı eylemler gerçekleştirecek dinamik alanlardır.

• Veritabanı Vakaları :Kullanıcı, kullanıcı adı ve şifresini girdikten sonra ilgili veri tabanını kontrol etmek için testler yazılabilir, kullanıcı adı ve şifrenin doğru veri tabanı ve tabloda kontrol edilip edilmediği ve ayrıca kullanıcının test edilen uygulamaya giriş izni olup olmadığı.
  

• Proses Testleri :Bu, özellik ve işlevsellikle ilişkili süreçle (ekranda bulunan görünür kontrollerle ilişkili eylemlerle değil) ilgilidir. Örneğin, Yukarıdaki örnek ekranda Şifremi Unuttum bağlantısına tıklamak kullanıcıya bir E-posta gönderebilir. Bu nedenle, uygun işlem ve onay için bir E-postanın test edilmesi gerekebilir.

4) Son olarak, ' BAOE mantrası ', anlamına geliyor i) Temel Akış ii) Alternatif Akış iii) Seçenekler ve iv) İstisnalar fonksiyonel akış ve test edilecek özelliğin tam kapsamı için. Her kavram pozitif ve negatif testlere uygulanmalıdır.

Örneğin, yukarıdaki örnek giriş ekranı için basit BAOE yaklaşımını görelim.

• Temel Akış: Herhangi bir tarayıcıda Oturum Açmanın URL yolunu girin ve gerekli bilgileri girin ve uygulamaya giriş yapın.
• Alternatif Akış: Uygulamayı bir mobil cihaza kurun ve gerekli bilgileri girin ve uygulamaya giriş yapın.
• Seçenekler: Aynı giriş ekranına gelmek için mevcut seçenekler nelerdir? Örneğin, Uygulamaya giriş yaptıktan sonra, 'Oturumu Kapat' ı tıklamak aynı ekranı getirebilir veya oturum zaman aşımı veya oturum sona ererse, kullanıcı oturum açma ekranına gelebilir.
• İstisnalar: Testlerim negatifse istisnalar nelerdir? Örneğin, Oturum açma ekranına yanlış kimlik bilgileri girilirse, kullanıcının bir hata mesajı alıp almayacağı veya hiçbir eylemle ilişkilendirilmeyeceği.

Elimizdeki tüm bu bilgilerle, giriş ekranı için TC'leri tam kapsamlı ve izlenebilir bir formatta ve detaylı bilgilerle yazmaya başlayalım. 'Yi tanımlamanın mantıksal sırası ve numaralandırması Test Vakası Kimliği ’ test senaryolarının hızlı bir tanımlama yürütme geçmişi için çok faydalı olacaktır.

Ayrıca oku=> Web ve masaüstü uygulamaları için 180'den fazla örnek kullanıma hazır test senaryosu.

Test Durumu Belgesi

Not : Test sütunları, eksiksiz bir izlenebilirlik matrisi, yani öncelik, testin amacı, test türü, hata ekran görüntüsü konumu için gereken sayıda sütuna sahip olacak şekilde bir excel sayfasında saklanabilen aşağıdaki örnek test belgesiyle sınırlı değildir. vb.,

Ayrıca oku=> Örneklerle örnek test senaryosu şablonu.

Bu belgenin basitliği ve okunabilirliği için, oturum açma ekranı için testlerin yeniden üretilmesi, beklenen ve gerçek davranışını aşağıda ayrıntılı olarak yazalım.

Not : Bu şablonun sonuna Gerçek Davranış sütununu ekleyin.

Test Verisi Toplama

Test senaryosu yazılırken, herhangi bir test uzmanı için en önemli görev test verilerini toplamaktır. Bu aktivite, test senaryolarının bazı örnek verilerle veya sahte verilerle yürütülebileceği ve veriler gerçekten gerekli olduğunda beslenebileceği varsayımıyla birçok test uzmanı tarafından atlanır ve gözden kaçar. Bu, test durumlarını yürütürken zihin hafızasından örnek verileri veya giriş verilerini besleyen kritik bir yanlış anlamadır.

Testler yazılırken veriler test belgesinde toplanmaz ve güncellenmezse, test uzmanı, testin yürütülmesi sırasında verileri toplamak için anormal şekilde daha fazla zaman harcar. Test verileri, özelliğin işlevsel akışının tüm perspektifinden hem olumlu hem de olumsuz durumlar için toplanmalıdır. İş kullanım durumu belgesi bu durumda çok kullanışlıdır.

Yukarıda yazılan testler için örnek bir test veri dokümanı bulun, bu da testin yürütülmesi sırasında işimizi kolaylaştıracak verileri ne kadar etkili bir şekilde toplayabileceğimize yardımcı olacaktır.

*************************************************

Test Durumlarını Standartlaştırmanın Önemi

Bu yoğun dünyada, hiç kimse aynı ilgi ve enerji düzeyiyle her gün tekrarlayan şeyler yapamaz. Özellikle iş yerinde aynı görevi tekrar tekrar yapma konusunda tutkulu değilim. İşleri yönetmeyi ve zamandan tasarruf etmeyi seviyorum. BT'deki herkes öyle olmalıdır.

Tüm BT şirketleri farklı türde projeler yürütür. Bu projeler ürün bazlı veya hizmet bazlı olabilir. Bu projelerin çoğu web siteleri etrafında çalışır ve web sitesi testi . Bununla ilgili iyi haber şu ki, tüm web sitelerinin birçok benzerliği var. Ve web siteleri aynı alan için ise, birkaç ortak özelliği de vardır.

Beni her zaman şaşırtan soru şudur: 'Örneğin, daha önce bin kez test edilmiş perakende siteleri gibi çoğu uygulama benzerse,' Başka bir perakende sitesi için neden sıfırdan test senaryoları yazmamız gerekiyor? ' Önceki bir perakende sitesini test etmek için kullanılan mevcut test komut dosyalarını çıkararak bir ton zaman kazandırmaz mı?

Elbette, yapmamız gereken bazı küçük değişiklikler olabilir, ancak genel olarak daha kolay, verimli, zamandan ve paradan tasarruf sağlar ve bu nedenle, test uzmanlarının ilgi seviyelerini her zaman yüksek tutmaya yardımcı olur. Kim aynı test senaryolarını tekrar tekrar yazmayı, incelemeyi ve sürdürmeyi sever, değil mi? Mevcut testleri yeniden kullanmak bunu büyük ölçüde çözebilir ve müşterileriniz de bunu akıllı ve mantıklı bulacaktır.

Mantıksal olarak, benzer web tabanlı projelerden mevcut betikleri çekmeye başladım, değişiklikler yaptım ve hızlıca gözden geçirdim. Ayrıca, yapılan değişiklikleri göstermek için renk kodlaması kullandım, böylece gözden geçiren yalnızca değiştirilen parçaya odaklanabilir.

Test Durumlarını Yeniden Kullanmanın Nedenleri

# 1) Bir web sitesinin en işlevsel alanları neredeyse giriş, kayıt, sepete ekleme, istek listesi, ödeme, gönderim seçenekleri, ödeme seçenekleri, ürün sayfası içeriği, son görüntülenenler, ilgili ürünler, promosyon kodu olanakları vb.

#iki) Projelerin çoğu, yalnızca mevcut işlevsellikte yapılan iyileştirmeler veya değişikliklerdir.

# 3) Görüntü yüklemeleri için boşlukları statik ve dinamik yollarla tanımlayan içerik yönetim sistemleri, tüm web siteleri için de yaygındır.

# 4) Perakende web sitelerinde CSR (Müşteri Hizmetleri) sistemi de.

# 5) JDA kullanan arka uç sistemi ve depo uygulaması da tüm web siteleri tarafından kullanılmaktadır.

# 6) Çerezler, zaman aşımı ve güvenlik kavramı da yaygındır.

# 7) Web tabanlı projeler genellikle gereksinim değişikliklerine eğilimlidir.

# 8) test türleri ihtiyaç duyulan tarayıcı gibi yaygındır uyumluluk testi , performans testi , güvenlik testi

Gördüğünüz gibi, yaygın ve benzer pek çok şey var.

Yeniden kullanılabilirliğin gitmenin yolu olduğunu söyledikten sonra, bazen değişikliklerin kendileri daha fazla veya daha az zaman alabilir veya almayabilir. Bazen kişi, çok fazla değişiklik yapmaktansa sıfırdan başlamanın daha iyi olduğunu düşünebilir.

Bu, ortak işlevlerin her biri için bir dizi standart test durumu oluşturarak kolayca halledilebilir.

Web Testinde Standart Test Nedir?

• Tam olan test senaryoları oluşturun - adımlar, veriler, değişken vb. Bu, benzer olmayan verilerin / değişkenin benzer bir test senaryosu gerektiğinde kolayca değiştirilebilmesini sağlayacaktır.
• Giriş ve çıkış kriterleri uygun şekilde tanımlanmalıdır.
• Değiştirilebilir adımlar veya adımlardaki ifade, hızlı bulma ve değiştirme için farklı bir renkle vurgulanmalıdır.
• Standart test senaryosu oluşturmak için kullanılan dil genel olmalıdır.
• Her web sitesinin tüm özellikleri test senaryolarında ele alınmalıdır.
• Test senaryolarının adı, test senaryosunun kapsadığı işlevselliğin veya özelliğin adı olmalıdır. Bu, setten test senaryosunun bulunmasını çok daha kolay hale getirecektir.
• Özelliğin herhangi bir temel veya standart örneği veya GUI dosyası veya ekran görüntüsü varsa, ilgili adımlarla birlikte eklenmelidir.

Yukarıdaki ipuçlarını kullanarak, bir dizi standart komut dosyası oluşturabilir ve bunları farklı web siteleri için çok az veya gerekli değişikliklerle kullanabilirsiniz.

Bu standart test senaryoları da otomatikleştirilebilir, ancak bir kez daha yeniden kullanılabilirliğe odaklanmak her zaman bir artıdır. Ayrıca eğer otomasyon bir GUI'ye dayanıyor, komut dosyalarını birden çok URL'de veya sitede yeniden kullanmak, kişisel olarak hiçbir zaman etkili bulmadığım bir şey.

Küçük değişiklikler içeren farklı web siteleri için standart bir manuel test senaryosu seti kullanmak, bir web sitesi testi gerçekleştirmenin en iyi yoludur. Tek ihtiyacımız olan test senaryolarını uygun standartlar ve kullanım ile oluşturmak ve sürdürmektir.

Sonuç

Test Durumunu İyileştirme Verimliliği basitçe tanımlanmış bir terim değildir, ancak bir egzersizdir ve olgunlaşmış bir süreç ve düzenli uygulama ile elde edilebilir.

Test ekibi, kalite dünyasında daha büyük başarılar için en iyi araç olduğundan, bu tür görevlerin iyileştirilmesine dahil olmaktan yorulmamalıdır; bu, görev açısından kritik projeler ve karmaşık uygulamalarda dünya çapındaki birçok test kuruluşunda kanıtlanmıştır.

Umarım Test Durumları kavramı hakkında geniş bilgi sahibi olursunuz. Test senaryoları hakkında daha fazla bilgi edinmek için eğitici dizilerimizi izleyin ve aşağıdaki yorumlar bölümünde düşüncelerinizi ifade etmekten çekinmeyin!

Sonraki Eğitim

Önerilen Kaynaklar

• Fonksiyonel Test ve Fonksiyonel Olmayan Test
• Pratik Örneklerle Taşınabilirlik Testi Kılavuzu
• Yazılım Testi Türleri: Ayrıntılarla Birlikte Farklı Test Türleri
• En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
• Alfa Testi ve Beta Testi (Tam Kılavuz)
• Sistem Testi Nedir - En İyi Başlangıç ​​Kılavuzu
• ISTQB Test Sertifikasyon Cevaplı Örnek Soru Kağıtları
• Yazılım Testi Haftalık Durum Raporu Nasıl Yazılır