Test planını kim yazmalı?

Şirketimin şirket içi geliştirme ekibindeyim ve şirketimizin web sitelerini pazarlama ekibinin gereksinimlerine göre geliştiriyoruz. Kabul testi için siteyi yayınlamadan önce, onlara takip etmeleri için bir test planı vermeleri istendi.

Bununla birlikte, geliştirme ekibi, gereksinimler talep edenlerden geldiğinden, neyi test edecekleri, nelere dikkat edecekleri, işlerin nasıl davranması gerektiği vb. Hakkında en iyi bilgiye sahip olacaklarını ve bu nedenle bir test planının gerekli olmadığını düşünmektedir. Biz her zaman bununla ilgili bir tartışma içerisindeyiz ve geliştiriciler bunun gibi şeyler yazmak için zaman kaybı buluyor:

1. A düğmesine tıklayın .
2. Anahtar XYZ form alan ve tıklama düğmesi B .
3. C davranışını görmelisiniz .

talep edilen her gereksinim / özellik için tekrarlamamız gerekir. Bu temel olarak gereksinimler belgesinde zaten olanları yeniden ifade etmektedir.

Projelerimizi yönetmek için Çevik bir yaklaşım kullanmaya doğru ilerliyoruz ve bu da her yinelemenin sonunda talep ediliyor.

Birim ve entegrasyon testleri bir yana, son kullanıcı kabul test planını kim oluşturacak? İstekliler mi yoksa geliştiriciler mi olmalı?

Şimdiden çok teşekkürler.

Saygılarımızla
CK

Test planı geliştiriciler tarafından YAZILMAMALIDIR. Test planının yapacağı şey, geliştiricinin gereksinimi doğru şekilde yorumlayıp yorumlamadığını kontrol etmektir. Bir geliştirici yazacağı kod üzerinde etkili bir şekilde bir test planı yazamaz. Test planları KG yapacak kişiler veya iş analistleri tarafından yazılmalıdır. Geliştiricilerin planları yazması gerekiyorsa, yazacağı programın bir kısmını planı yazmak için asla görevlendirmeyin.

Bunun, geliştirici tarafından yazılması gereken birim testleri tasarlamaktan farklı olduğunu ve beklediği şeyi yapıp yapmadığını görmek için yazdığı kodu test etmesi gerektiğini unutmayın. Ancak test planları, uygulamanın beklendiği gibi çalışıp çalışmadığını test etmek içindir ve bu, uygulamanın etkili olması için teknik olarak çalışmak üzere nasıl tasarlandığını bilmeyen biri tarafından yapılmalıdır.

KG ekibi test planını yazmalı ve uygulamalıdır.

İdeal olarak test planı fonksiyonel spesifikasyona paralel olarak yazılmalıdır - işlevselliği nasıl test edeceğinizin zihni nasıl yoğunlaştırdığı ve spesifikasyonu nasıl geliştirdiği şaşırtıcıdır.

Scrum cevabı: Eğer 'Yapıldı Tanımı'nı tanımlamak istiyorsanız, hızlı bir şekilde test planına sahip olmanın maddelerden biri olduğunu fark edeceksiniz. Test edilmediyse, yapılacak hikayeyi başka nasıl tanımlayabilirsiniz?

Test planını oluşturmaktan kim sorumludur? Takım

Takım kim? Ürünü gerçekleştirmeyi taahhüt eden herhangi bir kişi Ekibin bir üyesi olmalıdır.

Yani sizin durumunuzda, test planlarını yazabilecek olan kişiyi 'geliştirme ekibinize' dahil edebilir (veya kiralayabilirsiniz). Çevik'e taşınıyorsanız, geliştirmenin paralelinde bir test planı oluşturulduğunu göreceksiniz. Her ikisi de aynı hikayeden başlar ve iletişim yoluyla senkronize olur ve aynı anda teslim edilir. Paydaşların kritik gördüğü test senaryolarını geçmeden hikayenizi 'tamamlandı' olarak beyan etmemelisiniz.

Fonksiyonel test planlarının fonksiyonel / iş analistleri tarafından yazılması gerektiğini düşünüyorum. İşlevsel analizleri yazıyorlar (çevik çalışsanız bile, bazı analizleriniz olduğunu varsayıyorum) ve bu yüzden test amaçlı olarak uygulamadaki hangi yolların izlenmesi gerektiğini yazmalıdırlar.

Bu tamamen nasıl çalıştığınıza bağlıdır, ancak bence geliştiriciler, uygulamanın nasıl test edileceği, test etmek için hangi verilerin kullanılacağı vb. Hakkında fonksiyonel belgeler yazmamalıdır.

İşte her iki grubu da mutlu edebilecek ve Çevik bir yaklaşıma doğru ilerleyebilecek bir fikir :

Kullanıcı kabul kontrollerinizi otomatikleştirin ve ekran görüntüsü alın.

http://pragprog.com/magazines/2009-12/automating-screencasts

Yaşadığınız sorunun bir parçası gibi geliyor, yazdığınız test planlarının çok tekrarlayıcı ve tamamen doğrulayıcı olması. Dürüst olmak gerekirse, ne yazdığınızı hiç test etmiyorum - sadece gereksinimleri onaylıyorsa, kontrol ediyor . Bunu otomatikleştirmek ve screencasting, müşterileriniz için düzenli bir demo hazırlamanıza olanak tanır (hatta kısa bir gün içinde gönderebilirsiniz) - bir demoyu tıklayıp izlemek için bir test planı açmaktan daha olasıdır ve bunun üzerinde çalışmaya başlayın, umarım daha hızlı geri bildirim alırsınız (daha Çevik bir yaklaşıma doğru ilerliyorsanız çok önemlidir). Bileşenleri yeniden kullanabileceksiniz, böylece sizin için iş yükünü azaltacak,

Ayrıca gereksinimleri gerçekten yerine getirmenin bir yolunu sunar - Gojko Adzic'in yürütülebilir özelliklerine rastladınız mı? Buraya bir göz atın: http://gojko.net/2010/08/04/lets-change-the-tune/ Bunu, müşterilerinize demo yapmak için gereksinimleri yürütülebilir bir forma dönüştürmenin bir yolu olarak düşünüyorsanız , o zaman aniden daha az anlamsız görünüyor.

Şimdi, test cihazımın şapkasını taktığımda, screencast olayı çıkarsa, sizi / paydaşlarınızı bazı uygun testler yapmak için serbest bırakacağını belirtmekten onur duyuyorum - yani son durumları denemek ve gerçekten uygulamayı zorlayan testler yalnızca gereksinimleri onaylamak yerine. Ekran görüntülerini, daha fazla geri bildirim almak istediğiniz alanlar için kısa sorular veya önerilerle birlikte vermenizi öneririm, örneğin:

1) İşte yeni kayıt formumuz - nasıl çalıştığını görmek için bu ekran görüntüsünü izleyin!

Neler hakkında geri bildirimde bulunmak istiyoruz: Müşterilerin yanlış verileri giremediğinden emin olmak için bu forma çok fazla kontrol ekledik - müşterilerin ne zaman aldıkları hata mesajlarına bakmanızı gerçekten istiyoruz yanlış bir şey koymak ve bize müşterilerimizin onları anlamak kolay bulabilir olup olmadığını söyle.
Ayrıca bazı durumlarda çok katı olup olmadığımızı bilmek isteriz - özellikle sıra dışı müşteri verileriniz varsa (belki çok uzun bir ad mı yoksa gerçekten kısa bir ad mı yoksa adlarında alışılmadık karakterleri olan biri), ya da düşünmediğimiz başka bir şey, ya da adreslerinin sokak adı ya da bunun gibi garip bir şeyleri yok mu?) o zaman belki bunları denemek için birkaç dakika harcayabilirsiniz?

Yani güzel bir ekran görüntüsü sunuyorsunuz ve sonra geri bildirim istemek, çok spesifik olmadan çerçevelemek , sadece onaylamak yerine potansiyel konular hakkında düşünmelerini sağlamak. Onları alın düşünme sadece bir test planı ile körlemesine tıklamak yerine,. Temel olarak onlar için bir keşif testi belgesi yazıyorsunuz . ( Agile Testing Quadrantlara bakarsanız , bunlar Quadrant 3'teki testler olacaktır).

Örnek olarak evinizi yenileyin. Yükleniciniz tarafından sizin için ne yaptığını kontrol etmenizi isteyen bir kontrol listesini kabul eder misiniz? Yoksa kendi kontrol listenizi bulup yüklenicinin SİZİN belirttiğinizi yapıp yapmadığını kontrol eder misiniz?

Cevap açık: talep eden kişi talep ettiği şeyin spesifikasyonlara göre yapılıp yapılmadığını kontrol etmelidir. Kendi kontrol listesiyle çıkmalı ve uygulamayı test etmelidir. bu listeye karşı.

Bununla birlikte, geliştiricinin kendi kontrol listesi olması ve uygulamayı kullanmadan önce uygun dahili testlerin yapıldığından ve hataların giderildiğinden emin olması gerekir. UAT için bitti. İdeal olarak, geliştirici bu testlerin çoğunu test komut dosyaları şeklinde otomatikleştirmelidir. TDD'yi hatırlıyor musunuz? İdeal olarak, uygulama bileşenlerini test etmek için test komut dosyaları (bu durumda birim test senaryoları) yazılmalıdır. Daha sonra, entegre ve daha sonra regresyon testlerini gerçekleştirmek için bu birim test senaryolarını birleştirmek için test takımı yazılmalıdır.

Son kullanıcı kabul testi planı genellikle müşteriler veya müşteriyi temsil eden şirketteki bir iş ortağı tarafından yazılır. Müşterinin istediği özellikleri temsil etmesi gerekiyor ve KG'nin entegrasyon testini tamamlıyor. Ne QA ne de Development, kullanıcı kabul testlerini etkili bir şekilde planlayamaz, çünkü kullanıcı kabul testlerinin temel hedeflerinden biri, QA ve Development'ın müşterinin istediği düşüncenin gerçekten doğru olmasını sağlamaktır.