Menü

Bağlama Dayalı Test: Bir Örnekle 7 Temel İlke

context driven testing

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Bir Örnekle Bağlama Dayalı Testin 7 Temel İlkesi:

en iyi sürücü güncelleme yazılımı pencereleri 10

Havaalanına gittiğimde, genellikle beni oraya minimum sürede ulaştıracak ve gişelerden kaçınan otobanı kullanıyorum. Ama o gün, ücretli daha uzun bir yerel yol rotası kullandım. Çünkü hafta sonunu ailemizle geçirmek için çok uzun bir yol kat eden arkadaşımla arabayla birkaç dakika daha geçirmek istedim. Bu durumda normal en kötü seçim, en iyisi olarak ortaya çıktı.

Ama bunu bir düşünün.

Ya benzinim azalmış olsaydı?

Ya nakit param düşükse?

Farklı seçeneği seçerdim. Neden? Bağlam.

Bağlama dayalı test nedir

(resim kredi )

Aşağıdakilere dayalı kararlar verdiğinizde, aşağıdakiler bağlama dayalı bir karardır:

  • İlgili kişiler
  • Koşullar
  • Hedefler
  • Mevcut seçenekler
  • Duygular vb.

Peki, bağlama dayalı test nedir?

Bağlam Odaklı Test, Cem Kaner, James Bach ve Bret Pettichord tarafından geliştirilen bir zihniyet değişimidir (veya Test Okulu). Bununla ilgili ayrıntılar ünlü kitaplarında bulunabilir: Yazılım Testinden Alınan Dersler .

Bunun 7 temel prensibi vardır. Aşağıdakiler doğrudan kitaplarından seçilmiştir:

# 1) Herhangi bir uygulamanın değeri, içeriğine bağlıdır.

#iki) Bağlamda iyi uygulamalar vardır, ancak en iyi uygulamalar yoktur.

# 3) Birlikte çalışan insanlar, herhangi bir projenin bağlamının en önemli parçasıdır.

# 4) Projeler, genellikle tahmin edilemeyen şekillerde zamanla ortaya çıkar.

# 5) Ürün bir çözümdür. Sorun çözülmezse ürün çalışmaz.

# 6) İyi yazılım testi, zorlu bir entelektüel süreçtir.

# 7) Ürünlerimizi etkin bir şekilde test etmek için, yalnızca tüm proje boyunca işbirliği içinde uyguladığımız muhakeme ve beceriyle doğru şeyleri doğru zamanlarda yapabiliriz.

Her birini açıklamayacağım çünkü bu bizim için burada uzmanlar .

Bağlama Dayalı Test konusundaki yaklaşımımla ilgili senaryoya dayalı bir açıklama yapacağım.

Bağlam Odaklı Test Örneği:

Diyelim ki bir test projesi başlatıyorum - Web tabanlı bir uygulama için uçtan uca test içeren Proje A.

Benim stratejim ne olurdu?

Standart süreçlere göre bu, olayların sırası olacaktır:

  • Gereksinimleri toplayın ve uygulamayı anlayın
  • Bir Test planı oluşturun
  • Test belgeleri oluşturun - Test senaryoları, Test senaryoları, İzlenebilirlik Matrisi vb.
  • Tüm belgeleri gözden geçirip onaylatın
  • QA ortamını ve Test verilerini ayarlayın
  • Test yürütme gerçekleştirin
  • Hata raporları oluşturun
  • Test yürütme durum raporları vb. Oluşturun ve paylaşın.

Kendime şu soruyu sorarsam, 'Yapmam gereken şeyin bu olduğuna nasıl karar verdim?' Cevabım, en iyi uygulamalar, QA standartları, Sektör yönergeleri, geçmiş deneyim temelleri vb. Olacaktır, değil mi?

Bana yapmamın öğretildiği veya başkalarının yaptığını gördüklerimi tekrarlıyorum.

Şimdi, bunda bir sorun mu var? Bir şey değil. Bu da işe yarayabilir çünkü belirli bir tekrarlanabilirlik duygusu ve bu yaklaşım için zamana göre test edilmiştir. Ancak, en iyi sonuçların yolunu açıyor mu?

Şüpheli. Neden?

Çünkü her projede farklı durumlarla ilgileneceksiniz:

  • Belgelenmiş ve belgelenmemiş gereksinimler
  • Yakın çalışan ve coğrafi olarak dağılmış ekipler
  • Aynı şirkete ait Geliştirme ve Test ekipleri ile rekabete karşı
  • Yeterli zaman vs. Sıkı programlar
  • Ekibinizin bileşimi - Yeni gelenlere karşı deneyimli olanlar. Eğitimli ve eğitimsiz olanlar.
  • Araçların kullanılabilirliği - El ile Test yönetimi aracı kullanımı karşılaştırması
  • Proje türü - Kurallara (FDA veya bankacılık) ve deneysel (sosyal medya gibi) sıkı sıkıya bağlı kalması gerekir
  • Projenin teknolojisi.Örneğin:Web'i ve bir Windows uygulamasını aynı şekilde test edemezsiniz
  • Müşterilerin gereksinimleri (Bazıları günlük ayrıntılı raporlar ister, bazıları yalnızca öne çıkan konuları ister)
  • Takip edilen süreç (Çevik ve Geleneksel, komut dosyası içeren ve keşif amaçlı testler)

Bu liste kapsamlı değildir ve her projede birçok değişken olduğunu benim kadar iyi biliyorsunuz.

Bağlam odaklı test, standart, sektör tarafından algılanan '' yerine test uygulamalarınıza, tekniklerinize ve hatta tanımlarınıza bu koşulların karar vermesine izin verdiğiniz zamandır en iyi uygulamalar ’ .

Şimdi, bunlar A Projesi için üzerinde çalıştığım ayrıntılar diyelim:

  • 5-4 yeni gelen ve 1 deneyimli testçiden oluşan bir ekiple çalışıyorum.
  • Belgelenmiş gereksinimlerim yok.
  • Ekibim Hindistan'da ve geliştirme ekibi ABD'de, bu nedenle farklı saat dilimlerinde çalışıyoruz.
  • Müşteri, günlük ayrıntılı bir durum raporu istiyor
  • Mantis veya Bugzilla gibi web tabanlı bir hata izleme aracı kullanıyoruz ve sahip olduğumuz tek şey bu.
  • Test belgeleri için 10 günde 3 gün içinde 2 tur test yapmam gerekiyor

İşte kaba bir oyun planı:

1) Ekipte çok sayıda yeni oyuncu olduğu için bol miktarda akran incelemesine ihtiyacımız var.

iki) Ayrıca BA ve Dev ekibiyle en az 2 gereksinim tartışma toplantısına ihtiyacımız var. Bu resmi olmalı çünkü ekipler başka bir yerde bulunuyor ve onlara sorularla yaklaşmam için çok az alan var.

3) Belgeleme için agresif bir test zaman çizelgesidir. Ne kadar çok belge yazarsak, o kadar çok incelemeye ihtiyacımız var, bu da daha fazla zaman demektir. Bu nedenle, minimum belgeleri saklamamız gerekecek. Sadece ana olanı belgeleyeceğiz Uçtan Uca TC'ler ve gerisi olacak keşif yoluyla test edildi .

4) Test yürütme sırasında günlük durum raporları oluşturulacak ve her gün EOD gönderilecektir.

5) Çoğu test keşif amaçlıdır, bu nedenle, yapılan her testin kısa bir özetini çıkarmaya çalışmak için zaman tavsiye edin. Bu şekilde neyin test edildiğini ve neyin olmadığını biliyoruz.

6) Kusurlar gerçek zamanlı olarak Mantis'e bildirilecek. Ekip farklı bir saat diliminde çalıştığından, bir açıklamaya ihtiyaç duymaları durumunda QA ekibinden haber almak için tam bir gün beklemeleri gerekebilir. Bu nedenle, QA ekibinin hataların yeniden yaratılmasını göstereceği uygun bir ekipte günlük bir görüşme ayarlayın. Böylelikle etrafta beklemeye veya takip etmeye gerek kalmaz.

Ve bunun gibi.

Genel bir stratejiniz olduğunda, bu noktaları açıklayan temel bir test planı yazın. Şimdi, hepiniz dikkatli bir şekilde düşündükten sonra bir test projesine girmeye hazırsınız ve özel olarak başarı için bir strateji oluşturdunuz.

Özetle:

Bu Bağlama Dayalı test; Koşullarınızı (standartları değil) test stratejiniz için birincil girdiler ve etkileyiciler yapmak. Bizi etrafınıza bakmaya ve etrafınızdaki her şeyi hesaba katmaya teşvik ediyor.

Şahsen ben bu konsepte aşığım çünkü çoğu kez test uygulamaları katı ve taklit temelli olarak algılanıyor. Biri yaptı ve başarılı oldu, bu yüzden ben de yapacağım. Bu, insanları bir test kariyerini denemekten ve sürdürmekten korkutan türden bir imajdır.

Ancak yaratıcı düşünme, analitik beceriler ve karar verme için pek çok alan vardır. Daha fazlasını öğrenmek için, yukarıda verilen bağlantılarda konuyla ilgili bilgileri okuyun.

2 yıllık deneyim için php mülakat soruları ve cevapları

Mutlu bağlam odaklı testler

Önerilen Kaynaklar

^