È bello che i tester siano in competizione per vedere chi apre più bug?

Non penso sia giusto che facciano una gara per trovare il maggior numero di bug. Anche se è vero che il loro compito è trovare bug, il loro compito non è "trovare gli errori più ". Il loro obiettivo non è quello di trovare il massimo, il loro obiettivo è quello di contribuire a migliorare la qualità del software. Premiarli per trovare più bug è all'incirca come premiare un programmatore per scrivere la maggior parte delle righe di codice, piuttosto che il codice di massima qualità.

Trasformarlo in un gioco dà loro un incentivo a concentrarsi sulla ricerca di molti bug poco profondi, piuttosto che trovare i bachi più critici. Come hai detto nella tua modifica, questo è esattamente ciò che sta accadendo nella tua organizzazione.

Si potrebbe obiettare che qualsiasi bug trovato sia equo e che tutti i bug debbano essere scoperti. Tuttavia, dato che il tuo team probabilmente ha risorse limitate, preferiresti avere un focus sul tester per diverse ore o giorni che sondino profondamente nel tuo sistema cercando di trovare bug davvero grandi, o trascorri diverse ore o giorni a saltare nell'app cercando errori tipografici e piccoli errori nell'allineamento degli oggetti su una pagina?

Se la società vuole davvero fare un gioco, dare agli sviluppatori il potere di aggiungere punti a un bug. Gli "stupidi bug" ottengono punti negativi, difficili da trovare bug con report ben scritti che ottengono più punti. Questo sposta quindi l'incentivo da "trovare il massimo" a "essere il migliore nel fare il proprio lavoro". Tuttavia , questo non è raccomandato neanche perché un programmatore e un analista di QA potrebbero collaborare per riempire artificialmente i loro numeri.

Conclusione: non fare un gioco senza trovare bug. Trova modi nella tua organizzazione per premiare il buon lavoro e lasciarlo. La gamification premia le persone per il raggiungimento di un obiettivo. Non vuoi che un analista del controllo qualità abbia l'obiettivo di "trovare la maggior parte dei bug", vuoi che il loro obiettivo sia "migliorare la qualità del software". Questi due obiettivi non sono la stessa cosa.

Non accetto un po 'di dissenso con le altre risposte. "Trovare bug" per un tester è un po 'come "scrivere codice" è per uno sviluppatore. L'importo grezzo non ha senso. Il compito del tester è quello di trovare il maggior numero di bug esistenti che possono, non di trovare il maggior numero di bug. Se il tester A trova 5 dei 10 bug in un componente di alta qualità e il tester B trova 58 dei 263 bug in un componente di bassa qualità, allora il tester A è il tester migliore.

Vuoi che gli sviluppatori scrivano la quantità minima di codice per risolvere un particolare problema e vuoi che un tester stia scrivendo il numero minimo di rapporti che descrivono correttamente il comportamento interrotto. Competere per trovare il maggior numero di difetti è come competere per scrivere la maggior parte delle righe di codice. È troppo facile scivolare nel gioco per essere utile.

Se vuoi che i tester competano, dovrebbe essere più direttamente basato su ciò che sono lì da fare, che è quello di verificare che il software funzioni come descritto. Quindi forse le persone si sfidano per vedere chi può scrivere i casi di test più accettati o, ancora meglio, scrivere l'insieme di casi di test che coprono il maggior numero di codici.

La misura migliore della produttività degli sviluppatori è il numero di attività che completano la complessità delle attività volte. La migliore misura della produttività del tester è il numero di casi di test eseguiti tempi complessità del caso di test. Vuoi massimizzarlo, non trovare bug.

In base alle mie esperienze personali, questa non è una buona cosa. Porta quasi sempre gli sviluppatori a presentare bug che sono duplicati, ridicoli o completamente non validi. Di solito vedrete molti di questi apparire improvvisamente alla fine di un mese / trimestre mentre i tester si affrettano ad incontrare le quote. L'unica cosa peggiore è che penalizzi anche gli sviluppatori in base al numero di bug trovati nel loro codice. I tuoi team di test e di sviluppo stanno lavorando l'uno contro l'altro a quel punto e uno non può riuscire senza che l'altro sembri cattivo.

Devi mantenere l'attenzione sull'utente qui. Un utente non ha idea di quanti bug siano stati archiviati durante i test, tutto quello che vedono è quello che ha superato. Alla fine, gli utenti non si preoccupano se si registrano 20 segnalazioni di bug o 20.000, a condizione che il software funzioni quando lo ottengono. Una metrica migliore per valutare i tester sarebbe il numero di bug che sono stati segnalati dagli utenti, ma che avrebbe dovuto essere ragionevolmente catturato dai tester.

Questo è molto più difficile da tenere a mente, però. È abbastanza facile eseguire una query del database per vedere quante segnalazioni di bug sono state archiviate da una persona specifica, che sospetto sia il motivo principale per cui la metrica "bug archiviati" è utilizzata da così tante persone.

Non c'è niente di sbagliato nel fare un gioco senza trovare bug. Hai trovato un modo per motivare le persone. Questo è buono. Si è anche rivelato un fallimento nel comunicare le priorità. La fine del concorso sarebbe uno spreco. Devi correggere le priorità.

Pochi giochi reali hanno un semplice sistema di punteggio. Perché dovrebbe cacciare il bug?

Piuttosto che segnare il gioco semplicemente per numero di bug, devi fornire una misura della qualità del rapporto bug. Quindi il concorso è meno sul numero di bug. Sarà più come una gara di pesca. Tutti cercheranno di trovare il grande bug che otterrà un punteggio ad alta priorità. Rendi la qualità del bug report parte del punteggio. Chiedi agli sviluppatori di fornire ai tester un feedback sulla qualità del rapporto sui bug.

Il bilanciamento fine del gioco di tuning non è un compito semplice, quindi preparatevi a dedicare del tempo a farlo correttamente. Dovrebbe comunicare chiaramente i tuoi obiettivi e dovrebbe essere divertente. Sarà anche qualcosa che puoi modificare in base alle esigenze aziendali.

Trovare bug è il loro lavoro. Finché non rendono le cose meno efficienti (ad esempio, aprendo un bug per ech di 10 errori di battitura invece di uno per coprirne parecchie) questo è incoraggiante a fare esattamente quello che dovrebbero fare, quindi Non riesco a vedere molto di un rovescio della medaglia.

Questa è un'espansione sulla risposta di di CandiedOrange.

Per iniziare a spostare l'attenzione su obiettivi più utili, considera qualcosa di molto informale e non ufficiale. Ad esempio, gli sviluppatori potrebbero acquistare alcuni piccoli token e trofei.

Ogni giorno che è stato segnalato almeno un bug significativo, lascia un segnalino "Bug of the Day" sulla scrivania del tester. Una volta alla settimana, organizza una cerimonia con una processione di sviluppatori che consegna un gettone o trofeo "Bug of the Week" più grande e migliore. Rendi il trofeo "Bug of the Month" ancora più drammatico, magari con la torta. Ogni token o trofeo dovrebbe essere accompagnato da una citazione che spieghi perché gli sviluppatori pensavano che fosse una buona cosa che il bug fosse stato trovato nei test. Le copie delle citazioni dovrebbero essere messe da qualche parte dove i tester possono leggerle tutte.

La speranza è che i tester spostino la loro attenzione dal trovare la maggior parte degli errori nella raccolta della maggior parte dei trofei e dei token. La loro migliore strategia per farlo sarebbe quella di leggere le citazioni e pensare a quali approcci al testing sono suscettibili di far emergere bug che gli sviluppatori considereranno importanti.

Ignora semplicemente le segnalazioni di bug non importanti. Dal momento che sarebbe tutto molto non ufficiale e informale, potrebbe essere spento o modificato in qualsiasi momento.

Is this good for the project?

No . Hai fatto notare, da solo, che hai osservato che si traduce in rapporti di bassa qualità che non sono mirati alla funzionalità richiesta e che i tester finiscono per aggravare il problema, rimescolando per completare il lavoro che in realtà sono "supposti" "fare.

If not, how can I (as a software developer), try to change the thinking and attitudes of the team of testers?

Sollevare il problema con il tuo Project Manager. Dovrebbero considerare questo genere di cose come parte del loro lavoro. Se il tuo PM non è disposto o incapace di gestirlo, sei bloccato a sviluppare le tue strategie di coping. (che sarebbe una domanda diversa)

Penso che come sarà (o com'è già) se andrà avanti così, non otterrete necessariamente una qualità inferiore. Però penso che diminuirà il rapporto quantità / qualità. Dipende se questa è una brutta cosa o no. Dipende se

reporting bugs about screen enhancements, usability, or stupid bugs.

è qualcosa che davvero non vuoi. Se questo è chiaro con i tester, vorrei solo dire loro di non fare le cose che non vorreste riportare, ma di essere chiari al riguardo. Fallo quando uno di questi rapporti viene visualizzato di nuovo.

Il motivo per cui hanno una competizione è probabilmente quello di divertirsi durante il lavoro, quindi probabilmente non hanno intenzione di fare un brutto lavoro (se questo è considerato negativo).