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

Sono uno sviluppatore di software. C'è un team di tester che segue ed esegue casi di test scritti dall'analista, ma esegue anche test esplorativi. Sembra che i tester abbiano gareggiato per vedere chi apre più bug e ho notato che la qualità delle segnalazioni di bug è diminuita. Invece di testare la funzionalità e segnalare bug relativi al funzionamento del software, i tester hanno inviato bug su miglioramenti dello schermo, usabilità o stupidi bug.

È buono per il progetto? In caso contrario, come posso (come sviluppatore di software), provare a cambiare il pensiero e le attitudini del team di tester?

Un altro problema è dovuto al fatto che la scadenza è stimata e non può cambiare, quindi man mano che la scadenza si avvicina, i tester si affretteranno a completare i loro casi di test e questo causerà una diminuzione della qualità dei test. Ciò causerà bug legittimi nel prodotto finale ricevuto dal cliente.

OBS: questa competizione non è una pratica dell'azienda! È una competizione tra solo i tester organizzati da loro, e senza premi.

Non credo sia positivo che facciano una gara per trovare il maggior numero di bug. Mentre è vero che il loro compito è trovare i bug, il loro lavoro non è "trovare il maggior numero di bug". Il loro obiettivo non è quello di trovare di più, il loro obiettivo è quello di contribuire a migliorare la qualità del software. Premiarli per aver trovato più bug equivale a premiare un programmatore per aver scritto 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 superficiali, piuttosto che sulla ricerca dei bug più critici. Come accennato nella tua modifica, questo è esattamente ciò che sta accadendo nella tua organizzazione.

Si potrebbe sostenere che qualsiasi bug che trovano è un gioco equo e che tutti i bug devono essere scoperti. Tuttavia, dato che il tuo team probabilmente ha risorse limitate, preferiresti che un tester si concentri diverse ore o giorni a sondare a fondo il tuo sistema cercando di trovare bug davvero grandi, o passi diverse ore o giorni a saltare l'app cercando errori tipografici e piccoli errori nell'allineamento degli oggetti su una pagina?

Se la società vuole davvero farne un gioco, dai agli sviluppatori il potere di aggiungere punti a un bug. Gli "stupidi bug" ottengono punti negativi, difficili da trovare bug con segnalazioni ben scritte ottengono più punti. Questo sposta quindi l'incentivo da "trova di più" a "essere il migliore nel fare il tuo lavoro". Tuttavia , anche questo non è raccomandato, perché un programmatore e un analista di QA potrebbero collaborare per sommare artificialmente il loro numero.

Bottom line: non creare un gioco per trovare bug. Trova modi nella tua organizzazione per premiare il buon lavoro e lasciarlo a quello. La gamification premia le persone per aver raggiunto un obiettivo. Non vuoi che un analista di QA abbia l'obiettivo di "trovare il maggior numero di bug", vuoi che il suo obiettivo sia "migliorare la qualità del software". Questi due obiettivi non sono gli stessi.

Non condividerò un po 'le altre risposte. "Trovare bug" per un tester è un po 'come "scrivere codice" è per uno sviluppatore. La quantità grezza è insignificante. Il compito del tester è quello di trovare quanti più bug esistono che possono, non 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.

Volete che gli sviluppatori scrivano la quantità minima di codice per risolvere un problema particolare e volete che un tester scriva il numero minimo di report che descrivono correttamente il comportamento non funzionante. Competere per trovare il maggior numero di difetti è come competere per scrivere la maggior parte delle righe di codice. È fin troppo facile scivolare nel gioco per essere utile.

Se vuoi che i tester competano, dovrebbe essere più direttamente basato su cosa devono fare, vale a dire che il software funzioni come descritto. Quindi forse far competere le persone per vedere chi può scrivere i casi di test più accettati, o ancora meglio, scrivere l'insieme dei casi di test che coprono la maggior parte del codice.

La misura migliore della produttività degli sviluppatori è il numero di attività completate per la complessità delle attività. La misura migliore della produttività del tester è il numero di casi test eseguiti per la complessità del caso test. Vuoi massimizzare questo, non i bug trovati.

Sulla base delle mie esperienze personali, questa non è una buona cosa. Quasi sempre porta gli sviluppatori a presentare bug duplicati, ridicoli o completamente non validi. In genere vedrai molti di questi apparire all'improvviso alla fine di un mese / trimestre mentre i tester si affrettano a rispettare le quote. L'unica cosa peggiore di questa è quando penalizzi anche gli sviluppatori in base al numero di bug trovati nel loro codice. I team di test e sviluppo stanno lavorando l'uno contro l'altro a quel punto e uno non può avere successo senza far sembrare l'altro cattivo.

Devi concentrarti sull'utente qui. Un utente non ha idea di quanti bug siano stati archiviati durante il test, tutto quello che vedono è quello che ha superato. Alla fine, agli utenti non importa se si archiviano 20 segnalazioni di bug o 20.000, a condizione che il software funzioni quando lo ricevono. Una metrica migliore per la valutazione dei tester sarebbe il numero di bug segnalati dagli utenti ma che avrebbero dovuto essere ragionevolmente catturati dai tester.

Questo è molto più difficile da tenere traccia, però. È abbastanza semplice 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 creare un gioco per trovare bug. Hai trovato un modo per motivare le persone. Questo è buono. È stato anche rivelato un fallimento nel comunicare le priorità. Terminare il concorso sarebbe uno spreco. Devi correggere le priorità.

Pochi giochi reali hanno un semplice sistema di punteggio. Perché la caccia ai bug?

Invece di segnare il gioco semplicemente per numero di bug è necessario fornire una misura della qualità della segnalazione. Quindi il contest riguarda meno il numero di bug. Sarà più come una gara di pesca. Tutti cercheranno di trovare il grosso bug che otterrà un punteggio ad alta priorità. Rendi la qualità del bug report parte del punteggio. Chiedi agli sviluppatori di fornire ai tester feedback sulla qualità della segnalazione dei bug.

L'ottimizzazione del bilanciamento del gioco non è un compito semplice, quindi preparati a dedicare un po 'di tempo a farlo bene. Dovrebbe comunicare chiaramente i tuoi obiettivi e dovrebbe essere divertente. Sarà anche qualcosa che puoi regolare man mano che le esigenze aziendali cambiano.

Trovare i bug è il loro lavoro. Finché non stanno rendendo le cose meno efficienti (ad esempio, aprendo un bug per ech di 10 errori di battitura invece di uno per coprirne diversi) questo li incoraggia a fare esattamente quello che dovrebbero fare, quindi Non riesco a vedere un aspetto negativo.

Questa è un'espansione sulla risposta 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 token e trofei di piccole dimensioni.

Ogni giorno in cui è stato segnalato almeno un bug significativo, lascia un gettone "Bug del giorno" sulla scrivania del tester. Una volta alla settimana, organizza una cerimonia con una processione di sviluppatori che consegna un token o un trofeo "Bug della settimana" più grande e migliore. Rendi la consegna del trofeo "Bug of the Month" ancora più drammatica, forse con una torta. Ogni token o trofeo dovrebbe essere accompagnato da una citazione che spiega il motivo per cui gli sviluppatori hanno pensato che fosse una buona cosa trovare un bug nei test. Copie delle citazioni dovrebbero essere messe da qualche parte dove tutti i tester possono leggerle.

La speranza è che i tester possano spostare la loro attenzione dal trovare il maggior numero di bug alla raccolta del maggior numero di trofei e gettoni. La loro migliore strategia per farlo sarebbe quella di leggere le citazioni e pensare a quali approcci ai test rischiano di far emergere bug che gli sviluppatori considereranno importanti.

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

È buono per il progetto?

No . Hai sottolineato tu stesso 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, cercando di completare il lavoro che in realtà sono "supposti" "fare.

In caso contrario, come posso (come sviluppatore di software), provare a cambiare il pensiero e le attitudini del team di tester?

Solleva 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 affrontarlo, sei un po 'bloccato nello sviluppo delle tue strategie di coping. (che sarebbe una domanda diversa)

Penso che sarà (o com'è già) se andrà avanti così, non otterrai necessariamente una qualità inferiore. Anche se penso che ridurrà la quantità in rapporto alla qualità. Dipende se questa è una cosa negativa o no. Dipende se

segnalare bug su miglioramenti dello schermo, usabilità o stupidi bug.

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

Il motivo per cui hanno una competizione è probabilmente divertirsi mentre lavorano, quindi probabilmente non hanno intenzione di fare un cattivo lavoro (se questo è considerato cattivo).