Geliştiricilerin, test kullanıcılarının ve işletme kullanıcılarının birleştirilmiş bir test komut dosyası olmalı mı?

Geliştirme sırasında, normalde test etmeyi planladığım verileri, senaryoları ve yürütme adımlarını belgeleyecek kendi test komut dosyalarına sahip olurum; bu benim dev test planım. İşlevsellik Test'e dağıtıldığında, test kullanıcıları yazdıkları kendi test komut dosyalarını kullanarak test eder. UAT'de, işletme kullanıcısı daha sonra kendi test planlarını kullanarak test eder.

Geçmişe bakıldığında, testler ve iş kullanıcıları kara kutu testine odaklanırken, bu testlerin siyah ve beyaz kutu testlerinin bir karışımına sahip dev testleri ile daha iyi bir kapsama alanı sağladığı görülüyor. Ancak öte yandan, bu sadece aşama başına yürütülen farklı test senaryolarını getirir (yani testçilerin düşündüğü bazı vakalar sadece Test aşamasında yürütülür) ve geliştiricinin kaçırmasını ister, bu da onu bir bulgu / hata yapar .

Test komut dosyalarını baştan birleştirmeye değer mi? Yani bir birleşik test komut dosyası kullanarak, ya da bunu açıkça yapmak zor mu?

İlk olarak KG Test değildir. KG departmanınız tüm geliştirme sürecine dahil değilse, KG değil Testtir. QA işini yaparken kalite güvencesi sağlar, en iyi ihtimalle test kalite eksikliğini gösterir, ancak kalitenin var olduğunu kanıtlayamaz - yani test KG'nin başarısız olduğunu gösterir, ancak başarılı olduklarını gösteremez, bu nedenle Test ve KG aynı departman olmamalıdır.

En iyi yolun, her grubun daha iyi kapsama alanı sağladığı için kendi testlerini yönetmesini sağlamak olduğuna inanıyorum. Ancak, her takım en kısa zamanda teste başlamalıdır. Bu, Kullanıcıların kullanabileceği bir şey olduğunda UAT'ın başladığı, Test için test ettikleri bir parçanın hazır olduğu anda başlar, yani farklı test senaryolarının geç bulunmasını önler. Bu, UAT ve Test'in tam ürün üzerinde çalışmayı beklediği ve kısmen eksiksiz çıktıları test etmek için eğitim alması gerektiğinden, çalışma modellerinizde bazı yeniden düzenleme yapmak anlamına gelebilir. İş akışı disiplinli olmadığı ve geliştiricilerin "Tamamlandı" tamamlanmadığı sürece daha pahalı olabilir.

Kalite Güvencesi, sürecin sadece istenen kalite çıktısını sağlamakla kalmayıp, aynı zamanda uygun bir verimlilik düzeyinde de temin etmesini sağlamak için diğer kalite önlemleriyle birlikte bunu gözetmelidir.

Düzenleme: KG'ye orijinal soru referansı kaldırıldı, dolayısıyla bu cevap şimdi OT görünüyor.

UAT'leri en başından kullanıyoruz.

Evrensel bir referans gibi davranıyor ve bence iyi çalışıyor. Daha küçük bileşenler için yalnızca Devs veya Testers tarafından kullanılan test komut dosyaları olsa da, testin yönü her zaman bir birleşik hedefe işaret edilir. Günün sonunda, UAT önemli olan tek şeydir, böylece başlangıçta odaklanabilirsiniz.

UAT'leri en baştan yapmak da ek bir fayda sağlar. Müşteri beklentileri ile kendi beklentileriniz arasındaki belirsizliği gerçekten ortadan kaldırır.

Test ettikleri şeyler ve test yapma yöntemlerinin genellikle farklı olması gerektiği için tek bir test senaryosuna ihtiyaç duymazlar, ihtiyaç duydukları şey tüm tarafların üzerinde çalıştığı birleşik bir gereksinimdir. UAT ve QA, geliştiricinin hiç düşünmediği şeyleri test ediyorsa, gereksinimlere bakmanın zamanı geldi.

Devs, test kullanıcıları ve iş kullanıcıları için birleşik bir test senaryosuna sahip olmanın güzel olacağını kabul ediyorum, ancak maliyetin faydadan daha büyük bir çaba sarf etmeden mümkün olmadığına inanıyorum .

Zorluğun nedeni, her sistemdeki veritabanı içeriğinin farklı olması ve testlerin genellikle büyük ölçüde veritabanı içeriğine bağlı olmasıdır. "birleşik testlere" yaklaşımımız, her sistemin ek bir test veritabanı alması ve bu db'yi sıfırdan oluşturmak için komut dosyaları olmasıdır. test komut dosyaları, içeriğin standartlaştırıldığı testdb'ye karşı çalışır.

Mükemmel dünyada geliştiricilerin birim testleri (xUnit), test cihazları - otomatik entegrasyon testleri (Selenyum) ve iş kullanıcıları - kabul testleri (FIT) olmalıdır. Birbirlerine testlere erişebilirler.

Gerçekten projeye bağlı. Bazı durumlarda, bulguları tartışmak üzere toplanan birleşik bir Test, KG ve UAT ekibi oldukça faydalı olabilir. Test çabalarının tekrarını azaltır ve tüm tarafların UAT komut dosyaları aracılığıyla iş ihtiyaçlarını daha iyi anlamasını sağlar. Öte yandan, projenin karmaşıklığına bağlı olarak, iş örneklerini test etmeden önce girdi ve çıktıları tam olarak KG olarak kabul etmek daha mantıklı olabilir. Evde yetiştirilen sistem gelişimi için, kullanıcı kabulünden önce ilk KG zorunludur. Hazır uygulamalar için, birleşik bir test ekibi en mantıklıdır.