Testçilerin kimin daha çok böcek açtığını görmek için rekabet etmesi iyi mi?

Ben bir yazılım geliştiricisiyim. Analist tarafından yazılan test vakalarını izleyen ve yürüten, aynı zamanda keşif testi yapan bir test ekibi vardır. Test uzmanları kimin daha fazla böcek açtığını görmek için yarışıyor gibi görünüyor ve hata raporlarının kalitesinin düştüğünü fark ettim. Test işlevselliği ve yazılımın çalışmasıyla ilgili hataları bildirmek yerine, testçiler ekran geliştirmeleri, kullanılabilirlik ya da aptalca hatalar hakkında hatalar gönderiyorlardı.

Bu proje için iyi mi? Olmazsa (bir yazılım geliştiricisi olarak) test ekibinin düşünce ve tutumlarını nasıl değiştirebilirim?

Diğer bir sorun ise, son tarihin tahmini olduğu ve değiştirilemediğidir; bu nedenle, son tarih yaklaşırken test uzmanları test davalarını bitirmek için çabalıyorlar ve bu testlerin kalitesinin düşmesine neden oluyor. Bu, yasal hataların müşteri tarafından alınan son üründe bulunmasına neden olacaktır.

OBS: Bu rekabet şirketin bir uygulaması değil! Sadece kendileri tarafından organize edilen testçiler arasında ve herhangi bir ödül olmadan bir rekabet.

En fazla böcek bulma konusunda bir yarışma yapmanın iyi olacağını sanmıyorum. İşlerinin hata bulmak olduğu doğru olsa da, işleri "en fazla hata bulmak " değildir. Amaçları en fazla bulmak değil, amaçları yazılımın kalitesini arttırmaktır. Onları daha fazla hata bulma konusunda ödüllendirmek, bir programcının en yüksek kalitede kod yerine kod satırlarını yazmakla ödüllendirmekle aynıdır.

Oyunu oyuna sokmak, onlara en kritik hataları bulmak yerine, birçok sığ böceği bulmaya odaklanma konusunda bir teşvik sağlar. Düzenlemenizde bahsettiğiniz gibi, bu tam olarak organizasyonunuzda olan şeydir.

Bir kişi, buldukları herhangi bir hatanın adil bir oyun olduğunu ve tüm böceklerin keşfedilmesi gerektiğini savunabilir. Bununla birlikte, ekibinizin muhtemelen kaynakları sınırlı olduğu göz önüne alındığında, gerçekten büyük hatalar bulmaya çalışırken, sisteminize derinlemesine araştırma yapan birkaç saat veya gün boyunca bir test cihazı odaklanmasını mı yoksa tipografik hatalar veya küçük hatalar arayan uygulamalarda atlayarak birkaç saat veya gün geçirmenizi mi tercih edersiniz? Sayfadaki nesnelerin hizalanmasındaki hatalar?

Şirket gerçekten oyun oynamak istiyorsa, geliştiricilere bir hataya puan ekleme gücü verin. "aptalca hatalar" negatif puanlar alır, iyi yazılmış raporlarda hatalar bulmak zordur. Bu daha sonra teşviği “iş bulmakta en iyisi olmak” için “en fazlasını bulmak” dan hareket ettirir. Bununla birlikte , bu bir tavsiye edilmez, çünkü bir programcı ve KG analisti, sayılarını yapay olarak doldurmak için birlikte çalışabilir.

Alt satır: böcek bulmaktan oyun oynama. Kuruluşunuzda iyi çalışmaları ödüllendirmenin ve bu konuda bırakmanın yollarını bulun. Oyunlaştırma insanları bir hedefe ulaşmak için ödüllendirir. Bir QA analistinin “en fazla hata bulma” hedefine sahip olmasını istemezsiniz, amaçlarının “yazılımın kalitesini iyileştirme” olmasını istersiniz. Bu iki hedef aynı değil.

Diğer cevaplara biraz katılıyorum. Bir test cihazı için "hata bulma" biraz "geliştirici kodunu yazmak" gibidir. Ham miktar anlamsız. Test cihazının işi, bulabilecekleri birçok hatayı bulmak, en fazla hatayı bulamamaktır. A test cihazı 10 böceğin 5 tanesini yüksek kaliteli bir bileşende bulursa ve B test cihazı 263 böceğin 58 tanesini düşük kaliteli bir bileşende bulursa, o zaman A test cihazı daha iyi bir test cihazıdır.

Geliştiricilerin belirli bir sorunu çözmek için minimum miktarda kod yazmasını ve bozuk bir davranışı doğru şekilde tanımlayan minimum sayıda rapor yazmasını test eden bir kullanıcı istersiniz. En fazla kusur bulmak için rekabet etmek, en fazla kod satırını yazmak için rekabet etmek gibidir. Yararlı olması için sistemi oyuna sokmak çok kolaydır.

Test etmek isteyen test sahiplerine sahip olmak istiyorsanız, ne yapacaklarına bağlı olarak, yazılımın tanımlandığı şekilde çalıştığını doğrulamak için daha doğrudan olmalıdır. Bu nedenle, belki de en çok kabul edilen sınav senaryolarını kimin yazabileceğini görmek için rekabet etmeli, hatta en iyisi, en fazla kodu kapsayan sınav senaryolarını yazmalısınız.

Geliştirici verimliliğinin daha iyi ölçüsü, görevlerin karmaşıklığı ile tamamlanan işlerin sayısıdır. Test cihazı verimliliğinin daha iyi ölçülmesi, test vakası karmaşıklığının yapıldığı test vakalarının sayısıdır. Bu hata bulmak değil, en üst düzeye çıkarmak istiyorum.

Kişisel deneyimlerime dayanarak, bu iyi bir şey değil. Neredeyse her zaman geliştiricilerin kopya, saçma ya da tamamen geçersiz olan dosyalama hatalarına neden olur. Testçiler kotaları karşılamak için acele ederken, genellikle bir ay / çeyrek sonunda aniden beliren birçoğunu görürsünüz. Bundan daha kötüsü olan tek şey, geliştiricilere kodlarında bulunan hata sayısına göre de ceza vermenizdir. Test ve geliştirme ekipleriniz bu noktada birbirlerine karşı çalışıyorlar ve biri diğerini kötü göstermeden başaramıyor.

Odak noktanızı burada kullanıcı üzerinde tutmanız gerekir. Bir kullanıcı, test sırasında kaç tane hatanın dosyalandığına dair hiçbir fikre sahip değildir, tüm gördükleri, başından geçenlerden biridir. Kullanıcılar sonuçta, yazılım çalıştıklarında çalıştığı sürece 20 hata raporu veya 20.000 dosyalamanızın umrunda değil. Test edicileri değerlendirmek için daha iyi bir ölçüm, kullanıcılar tarafından bildirilen ancak test ediciler tarafından makul şekilde yakalanması gereken hataların sayısı olacaktır.

Yine de, takip etmesi çok daha zor. Belli bir kişi tarafından kaç tane hata raporunun yayınlandığını görmek için bir veritabanı sorgusu çalıştırmak oldukça kolaydır, bu nedenle "dosyalanan hatalar" metriğinin bu kadar çok kişi tarafından kullanılmasının ana nedeni olduğundan şüpheleniyorum.

Hata bulmaktan oyun çıkarken yanlış bir şey yoktur. İnsanları motive etmenin bir yolunu buldun. Bu iyi. Aynı zamanda önceliklerin iletilemediğini de ortaya koydu. Yarışmayı sonlandırmak israf olur. Öncelikleri düzeltmen gerekiyor.

Birkaç gerçek oyunun basit bir puanlama sistemi var. Böcek neden avlanmalı?

Oyunu sadece hataların sayısına göre puanlamak yerine, hata raporu kalitesinin bir ölçüsünü vermeniz gerekir. Öyleyse yarışma böcek sayısından az. Daha çok balık avlama yarışması gibi olacak. Herkes yüksek öncelikli puan alacağınız büyük hatayı bulmaya çalışacak. Hata raporunun kalitesini puanın bir parçası haline getirin. Geliştiricilere testçilere hata raporunun kalitesi hakkında geri bildirimde bulunmalarını sağlayın.

İnce ayar oyun dengesi basit bir iş değildir, bu yüzden bu hakkı almak için biraz zaman harcamak için hazırlıklı olun. Hedeflerinizi açıkça belirtmeli ve eğlenceli olmalıdır. Ayrıca, işletme ihtiyaçları değiştikçe ayarlayabileceğiniz bir şey olacaktır.

Hata bulmak onların işidir. İşleri daha az verimli hale getirmedikleri sürece (örneğin, birkaçını örtmek yerine 10 yazım hatası için bir böcek açarak) bu, tam olarak yapmaları gereken şeyi yapmalarını teşvik eder. Bir dezavantajı çok göremiyorum.

Bu @ CandiedOrange en üstünde bir genişleme cevap .

Dikkatleri daha faydalı hedeflere kaydırmaya başlamak için gayri resmi ve gayri resmi bir şey düşünün. Örneğin, geliştiriciler bazı küçük jetonlar ve ödüller alabilirler.

En az bir önemli hatanın bildirildiği her gün, test cihazının masasında bir "Günün Böceği" belirteci bırakın. Haftada bir, daha büyük ve daha iyi bir "Haftanın Böceği" belirteç ya da kupasını veren geliştiricilerin alayıyla bir tören düzenleyin. "Ayın Böceği" ödülünü, belki pasta ile daha da çarpıcı hale getirin. Her belirteç ya da kupaya, geliştiricilerin test etmede hatanın bulunmasının iyi bir şey olduğunu düşündüğünü söyleyen bir alıntı eşlik etmelidir. Alıntıların kopyaları, test edicilerin hepsini okuyabileceği bir yere konulmalıdır.

Umut, test uzmanlarının dikkatlerini en fazla hata bulmaktan ve en çok kupa ve jeton toplamaya yönlendirmek zorunda kalmalarıdır. Bunu yapmak için en iyi stratejileri, alıntıları okumak ve hangi test yaklaşımlarının geliştiricilerin önemli olduğunu düşündüğü hataları ortaya çıkarması gerektiğini düşünmektir.

Sadece önemsiz hata raporlarını görmezden gelin. Hepsi gayri resmi ve gayri resmi olacağından, herhangi bir zamanda kapatılabilir veya değiştirilebilir.

Bu proje için iyi mi?

Hayır . Kendini, gerekli işlevselliği hedeflemeyen düşük kaliteli raporlarla sonuçlandığını ve test edicilerin sorunu çözdüğünü, gerçekten de oldukları işi tamamlamak için çabalıyorlar olduğunu belirttiniz. "yapmak için.

Olmazsa (bir yazılım geliştiricisi olarak) test ekibinin düşünce ve tutumlarını nasıl değiştirebilirim?

Sorunu Proje Yöneticinizle yapın. Bu tür şeyleri işlerinin bir parçası olarak düşünmelidirler. Başbakanınız onunla başa çıkmakta isteksiz ya da baş edemiyorsa, kendi başa çıkma stratejilerinizi geliştirmek için takılıp kalmışsınızdır. (farklı bir soru olurdu)

Ben böyle devam ederse nasıl olacağını (veya halihazırda nasıl olacağını) düşünüyorum, mutlaka daha düşük kaliteye sahip olmayacaksınız. Yine de miktarın kalite oranını azaltacağını düşünüyorum. Bu kötü bir şey olup olmamasına bağlıdır. Bağlıdır

ekran geliştirmeleri, kullanılabilirlik veya aptal hatalarla ilgili hataları bildirme.

Gerçekten istemediğin bir şey . Bu, test edicilerden açıkça anlaşılıyorsa, onlara sadece bildirilmesini istemediğiniz şeyleri yapmalarını değil, netleşmelerini söylerim. Bu raporlardan biri tekrar göründüğünde bunu yap.

Rekabet etmelerinin nedeni muhtemelen çalışırken eğlenmek, bu nedenle muhtemelen kötü iş yapmak istemiyorlar (eğer kötü kabul edilirse).