Otomatik kabul testleri ile% 100 kullanıcı hikayesi kapsamı içeren BDD kullanarak bir proje yürütürseniz, bir test / kalite güvence görevlisinin rolü ne olur?
Sanırım geliştiricilerin kabul testlerini ürün sahibiyle birlikte yazacaklarını düşünüyorum, bunun aptalca bir varsayım gibi olup olmadığını bana bildirin.
Yanıtlar:
Belki çok eski modayım, ancak en modern geliştirme veya süreç teknikleri bile müşterinize bir ürün yayınlamadan önce başka bir göz, taze göz seti yerine geçemez.
Ürününüz yalnızca başka bir geliştirici için bir API olsa bile, sizin veya müşterinizin önceden düşünmediği test / kullanım senaryoları sağlayarak API kullanıcısı olarak düşünmek için KG'yi kullanabilirsiniz.
Ürününüz ağır bir şekilde kullanıcı arayüzüne dayanıyorsa, müşteriye göndermeden önce kesinlikle başka bir kişinin (sizin veya ekibinizin biri değil) nihai sonuca bakmasını istiyorsunuz.
Sanayimizdeki diğer terimlerde olduğu gibi BDD -% 100 kapsama alanına sahip olsa bile - gümüş kurşun değildir .
% 100 kapsama alanı,% 100 test edilenle aynı değildir.
Bir ATDD projesinde bir KG kişisini, testleri yazmaya ve hala var olan diğer test türlerini gerçekleştirmeye yardımcı olacak biri olarak görüyorum. II Kullanıcı Arayüzü Testi, imha testi ve yük / gerilim testleri.
Ama hiç ATDD projesi yapmadım.
QA'nın işi uygulamayı kırmaktır, devs işi onu kırmamaktır. Bu nedenle testlerini farklı bir perspektiften yazarlar. Örneğin devs, beklenen davranışın gerçekleşip gerçekleşmediğini görmek için testler yazıyor, KG, kullanıcılar geliştiricinin kullanıcının asla yapamayacağını düşünmeyeceği bir şey yaptığında ne olacağını görmek için testler yazıyor. Ayrıca, geliştiriciler genellikle gereksinimleri yanlış yorumlamaktadır ve KG testleri, yorumları geliştiricinin düşündüğünden farklı olduğunda yakalanacak ve daha sonra doğru yorumun hangisi olduğunu belirlemek için proje paydaşlarıyla bir araya gelecektir. Kodu yazan geliştiriciler tarafından yazılan testlerin genellikle büyük kör noktaları vardır, çünkü geliştiricinin büyük bir kör noktası vardır. Örneğin, zamanın% 97'sinde neler olduğunu test edebilir, ancak kenar durumları test edemez.
Önceki bir işverende KG'nin rolü ürünü test etmemek, ancak geliştiricilerin QA tarafından tanımlanan önceden tanımlanmış kabul testleri ile ilgili yapacaklarını söyledikleri şeyi yaptıklarını garanti etmekti.
Öte yandan, ürün sahibinin testle kesinlikle ilgisi yoktu. Herhangi bir seviyede testle uğraşmak IMHO, ürün sahibinin rolü değildir.
Bir noktada çalışanlarınıza güvenmelisiniz; kontroller ve dengeler iyidir ancak geliştirme döngüsünde gerçekte çalışanların iş ahlakının sadece küçük bir alt kümesine hitap edecek bir çözümü zorlamak zorunda kalmamalısınız.
Mükemmel bir dünyada dev ve QA ile işbirliğini kabul testlerinin ortak bir şekilde yazılmasıyla resmileştirdiğini görüyorum. KG, geliştirme ekibine olduğu gibi tabloya da farklı bir yön getirmelidir. KG, ürünün bebeklik döneminde pastada eline sahip olmalı ve tüm döngü boyunca bağlı kalmalıdır. Öte yandan, ürün sahibi ürünün mevcut durumu, riskler vb. Hakkında bir anlayış için KG'ye katılmalı ve ürüne bütünsel bir şekilde odaklanmalıdır; ürünü oluşturan özel nüanslar değil.
Deneyimlerime göre: Kodun% 90'ından fazlasını kapsamak için Birim testi kullanıyorduk. Ayrıca entegrasyon testleri ve saatlik sürümler de vardı. BDD için testler yapın.
KG rolü: - test için kullanıcı hikayelerini benimseme - adımların arkasına kod yazma - IDEA için RestClient eklentisini kullanarak keşif testi (böylece bazı büyük hatalar bulduk)
BDD'nin bir kısmı, paydaşların kabul kriterlerini oluşturmak için işbirliği yaptığı 3 Amigos yaklaşımını uyguluyor. KG / Dev, senaryoların kabul testi olarak yürütülmesini sağlamak için adım kodunu yazabilir. Bir BDD aracının otomatik olarak yürüteceği kabul testlerini manuel olarak yürütmek için KG'nin değeri nerede? KG'nin katma değeri, bu kabul testlerini doğrulamak ve kodlanmış kabul testleri dışında manuel keşif testi yapmaktır. Çoğaltma genellikle aynı sonucu verir.
Geliştiriciler gereksinimleri ve özellikleri yeniden yazmazlar, KG uygulama kodunu yeniden yazmaz ... KG'nin, geliştiricilerin kabul testleri olarak yürüttüğü komut dosyası testlerini gerçekleştirmesi gerekmez. Devs için bazı QA şapka takma zamanı!