Test uzmanları çalışmalarını otomatikleştirmeli mi?

Test sürecimizi kurmaya çalışıyoruz. Testçilerimizin otomatik regresyon testleri geliştirmesi gerekip gerekmediğini veya geliştiricilerin bunu yapması gerekip gerekmediğini merak ediyoruz.

Peki ya diğer otomatik test türleri? Test kullanıcıları bunları geliştirmeli mi?

Testçilerin otomatik testler geliştirmeleri gerektiğini söylüyorum - koda "dış göz çifti" yaklaşımına sahipler ve düşünmediğiniz hataları ele alalım. .

Ayrıca, işlevsel gereksinimleri anlamaları geliştiricilerin anlayışından daha yüksek olabilir - bu nedenle programlayıcının düşük seviye bilgisi arasında oturmak, ancak BA'nınkinden daha yüksek seviyede olmamak.

Otomatikleştirebiliyorsanız, otomatikleştirin.

Otomatikleştiremeyeceğiniz şeyleri bulmak için test kullanıcılarını serbest bırakın. Ve yeni bir hata bulduklarında, otomatikleştirilip otomatik testlere eklenebiliyorsa, ekleyin.

Bence, geliştiriciler ve test uzmanları farklı test türlerinden sorumludur.

Geliştirici, mantığı yazarken, birim ve entegrasyon testleri de yazmalıdır. Bu, geliştiricinin şimdiye kadar yazdıklarının amaçlandığı gibi çalıştığından emin olmasını sağlayacaktır. Ayrıca, bu testler geliştiricinin gelecekteki değişiklikleri yaptıklarında da çalışmaya devam edecektir. Mantık tamamlandıktan sonra, geliştirici, yazılanların özellikleri anladıkları ve test cihazına geçebildiklerinden emin olabilir.

Bu noktadan itibaren test cihazı, iş mantığının istendiği gibi çalıştığından emin olmak için sistem çapında testler yazmaktan sorumlu olmalıdır.

Geliştiricilerin genellikle koda çok fazla bağlı olduğu göz önüne alındığında, test kullanıcıları geliştiricinin testlerini temizlemeye yardımcı olmalı, ancak tam tersi olmamalıdır.

Deneyimlerime göre, bir test cihazının bir test senaryosunu otomatik olarak ayarlama ve yürütme şekli aslında geliştiricinin yaptığı işlemden farklıdır. Testçiler, test durumundan en fazla bilgiyi nasıl elde edeceklerini, testlerin hızlı bir şekilde nasıl yürütüleceğini, testlerin nasıl sürdürülebileceğini ve daha fazlasını düşüneceklerdir. En önemlisi, test kullanıcıları geliştiricilerin kaçıracağı test kapsamının nüanslarını görecekler.

Test geliştirme kaynakları düşükse, geliştiriciler yardımcı olabilir - ancak bir testçi çalışmalarını dikkatle incelemelidir. Geliştiriciler, gerçek test senaryoları yazmadan önce fikstürler ve test araçları üzerinde çalışmalı ve geliştiriciler asla kendi kodları için test senaryoları yazmamalıdır. Geliştiricilerin testlerde yardımcı olması avantajlıdır - geliştiricileri ürünün diğer parçalarına maruz bırakır ve testler daha iyi geliştiriciler olmalarına yardımcı olabilir. Ancak, küçük bir geliştiricinin çalışması hiçbir zaman bir kod incelemesi olmadan gitmeyecek gibi, bir geliştiricinin KG çalışması daha fazla deneyim testi olan birinden bir KG incelemesi almalıdır.

Eklemek için düzenlendi: 5 yıllık deneyime sahip bir SDET'im. Her biri 10 yıldan fazla deneyime sahip büyük geliştiricilerle çalışıyorum ve son zamanlarda bir test darboğazından geçmek için onlarla birlikte çalışıyorum.

Gerçekten görmek istediğim bir şey, test kullanıcıları için ilerlemelerini bir test komut dosyası aracılığıyla etkili bir şekilde kaydetmelerine ve daha sonra bu komut dosyasının gelecekte otomatik olarak çalışmasına izin verecek sağlam otomasyon araçlarıdır. Özellikle bu, aynı komut dosyasının test cihazının hepsinden elle geçmesine gerek kalmadan farklı işletim sistemi sürümlerinde çalıştırılmasını kolaylaştırırsa.

Ne yazık ki, kesinlikle üzerinde çalıştığım ürün için, piyasadaki araçların hiçbiri işi yapmıyor. Ama bunu akılda tutmaya ve yaptığınız şey için işe yarayacak bir şey olması durumunda piyasada mevcut olanlara bakmaya değer.

Burada gerçekten önemli olan önemli bir ayrım şudur: Test kullanıcılarınız basitçe kontrol ediyorlar mı yoksa test mi ediyorlar ?

Michael Bolton'un bu blog yazısı daha iyi açıklıyor, ama özünde: sadece davranışı doğrulamak mı istiyorlar, yoksa sistemle ilgili sorunları mı bulmak istiyorlar?

Agile Testing Quadrants'ı düşünmenin de yararlı olduğunu düşünüyorum (Brian Marick başlangıçta bunları açıkladı, ancak Lisa Crispin ve Janet Gregory'nin "Agile Testing" kitabında karşılaştım: Agile geliştirme yöntemini takip etmiyor olsanız bile, ürünü eleştiren testler ile ekibi destekleyen testler arasındaki ayrım, otomasyonu düşünürken ve kimin neyi neden yaptığını gösteren bir plan geliştirmeye gerçekten değer.

Örneğin, geliştiriciler tarafından yazılan birim kontrolleri, değişiklik dedektörleri gibi davranarak, düzenli olarak tekrar çalıştırıldıklarında gerilemeleri erken yakalamanızı sağlar - bunlar takımı destekleyen testlerdir. Düzenli ve hızlı bir şekilde tekrar çalıştırılabilmeleri için otomatikleştirilmiş sistem düzeyinde regresyon kontrolleri, regresyonları erken yakalayarak ekibi destekliyor ve geliştiriciler tarafından yapılan birim testlerini tamamlıyor. Bu, testçilerinizin, örneğin ürün keşif testlerini eleştiren testler yapma süresini kısaltır. Ya da ürünü test etmek için otomatik kontrollerin bazılarını uygulamak mümkündür.

Bağlantı kurduğum Lisa Crispin sunumu hakkında gerçekten sevdiğim bir diğer şey, otomasyonun manuel testi desteklemek için de kullanılabileceğine dikkat çekiyor - test verileri oluşturmak, bugün odaklanmak istediğiniz noktaya bir senaryo elde etmek için kullanılan otomasyon, çünkü misal.

Bu iki makaleyi dikkate almak, ne tür testler yapmak istediğinizi analiz etmenize, otomasyon için neyin uygun olabileceğini seçmeyi ve test otoriteleri tarafından hangi otomasyon parçalarının daha uygun olduğunu belirlemenizi kolaylaştıracaktır. geliştiriciler tarafından.