Sistema di segnalazione bug: far sì che le persone lo usino

Sembra che tu stia "influenzando" un cambiamento nella cultura, che richiede tempo. Inoltre, i sistemi di gestione dei bug sono un costo pesante, soprattutto perché abbiamo i nostri account di posta elettronica aperti tutto il giorno in background, ma per un sistema di gestione bug, viene chiesto all'utente di aprire un altro sistema che devono imparare ad usare, ecc. .

Alcune cose che puoi provare:

• Coinvolgi il leader del progetto e discuti dell'importanza di non perdere bug.
  • Se ci sono stati errori che sono stati persi, portalo come caso di studio.
• Puoi avere regolari incontri di stato (o triage) eseguiti solo dal sistema di segnalazione dei bug.
• Invia report a livello di team (specialmente se il tuo project leader può farlo), che mostra chi ha aperto quanti bug e quanti sono assegnati a ciascun ingegnere, che vedrà le persone realizzare il "beneficio" che ottengono (es. sarà felice quando avranno fama a causa della pubblicità di bug, ecc. Come tester, questa è stata una grande caratteristica dei sistemi di gestione dei bug per me :-))
  • Ho usato strumenti che generano automaticamente segnalazioni di bug e li invio al team o hanno widget desktop, ecc.
• Puoi considerare di integrare il tuo sistema di gestione dei bug con le e-mail, quindi se una e-mail viene inviata al team insieme a un indirizzo speciale, si aprirà automaticamente un bug.
  • Se qualcuno vede un'e-mail che è un bug, può aggiungere l'alias del sistema di gestione dei bug a cc e così via. Molti sistemi di gestione degli incidenti adottano questo approccio.

Nonostante tutto questo, potresti ancora avere alcuni bug che mancheranno perché le persone tendono ad avviare discussioni via email chiedendo un comportamento e molto presto si scopre che è un bug, e nessuno ne apre uno nel sistema di gestione dei bug. Avere quell'integrazione di e-mail può essere d'aiuto, ma poi questi problemi devono essere gestiti lungo il cammino ...

Se i segnalatori di bug sono normali utenti, posso capire perché preferirebbero contattarti via email. Immaginiamo che io sia un utente normale e voglio segnalare un bug.

Modulo di segnalazione bug

Innanzitutto, riporta un modulo di errore. Nonostante i tuoi tentativi, non è intuitivo .

1. Quale dovrebbe essere la priorità del bug che voglio segnalare? Se lo metto troppo in alto, temo che gli sviluppatori mi diano la colpa che ritengo che i bug che ho segnalato siano più importanti di altri bug. Se lo metto troppo in basso, gli sviluppatori potrebbero non leggerli mai.

2. Qual è l'argomento? Hm. Nessuna idea. Che ne dici di "Un bug"? Sembra stupido.

3. Il modulo chiede di descrivere il bug. Dovrei iniziare salutando la persona che leggerà il rapporto o mantenerlo impersonale? Dovrei specificare il contesto, dato che il modulo chiede di parlare solo del bug stesso?

4. Il modulo mi chiede di allegare uno screenshot. Ma il bug non è visivo. Posso saltare questo passaggio? Il modulo non mi dice se posso.

5. E-mail. Ok. Cosa succede se non mi interessa la risposta, e temo che mi manderai spam?

6. Se controllo che voglio informare tutti, notificherebbe a tutti gli sviluppatori di un team? Ogni persona incaricata di leggere i bug? O forse il bug report diventerà pubblico e chiunque sarà in grado di leggerlo? Sembra spaventoso.

Processo di segnalazione dei bug

Parlando dell'ambiente:

1. Voglio tenere traccia del bug report, perché c'è un'altra società che ha ricevuto centinaia di segnalazioni di bug da me, che non ha mai risposto e non le ha mai risolte. Quando ho contattato il loro supporto, hanno detto che non hanno mai ricevuto nulla da me. Che peccato. Con le email, avrei potuto mostrare loro che effettivamente ho segnalato qualcosa.

2. Che cosa accadrebbe effettivamente una volta inviato il modulo?

3. C'è una persona dietro a questo? Parlare con una persona è una cosa. Riempire un modulo senza sapere se è letto da qualcuno è una cosa diversa. Potresti dire che dover scrivere su [email protected] è abbastanza impersonale; è per questo che in molti prodotti puoi contattare una persona.

"Bug" term

Infine, la terminologia. Cosa dovrebbe essere segnalato?

• Se si tratta di un'eccezione non gestita in un prodotto software, perché dovrei segnalarlo? Non dovrebbe essere segnalato automaticamente?

  In realtà, dovrebbe. Questo è esattamente il comportamento dei prodotti come VLC o Chrome.

• Se si tratta di un HTTP 500 in un'applicazione Web, perché dovrei segnalarlo? Dovrebbe essere fatto automaticamente.

• Se si tratta di un bug reale che non causa un'eccezione non gestita o un HTTP 500, allora e solo allora il modulo può essere utilizzato.

• Se è una funzione di cui ho bisogno, preferirei contattare l'azienda via email piuttosto che segnalare un bug, poiché è non un bug.

• Se si tratta di un errore di battitura, una traduzione sbagliata, un problema di accessibilità, ecc., di nuovo, pochi lo considerano un bug. Pertanto, la forma è irrilevante e le e-mail appaiono più appropriate.

• Se si tratta di una richiesta legale ("La tua app ha cancellato tutti i miei file quindi ti denuncio"), dovrebbe essere effettuata per posta o, in alcuni casi, per e-mail, non compilando una segnalazione di bug.

• Se è un'altra cosa, un feedback via email sembra ancora più appropriato di un bug report.

Conclusione

I segnalatori di bug potrebbero non essere propensi a utilizzare il modulo perché:

• Hanno sempre fatto così (vedi la risposta di Omer Iqbal ),

• Potrebbero aver provato e sono rimasti intrappolati in quei sistemi di tracciamento dei bug estremamente complicati,

• Il modulo non è intuitivo,

• Il modulo non dà un suggerimento su cosa succederà dopo,

• Il modulo parla di bug, che esclude un sacco di cose che possono essere soggette a feedback ma che non sono esattamente bug, come errori di battitura o problemi di accessibilità.

Per incoraggiare gli utenti a utilizzare effettivamente il modulo, puoi:

• Rendilo più intuitivo,

• Rendilo meno impersonale,

• Spiega meglio cosa accadrà una volta inviato il bug,

• Modifica la terminologia, se necessario.

Infine, perché non mescolare entrambe le email e i rapporti attraverso un modulo? FogBugz lo fa.

O se i rapporti via e-mail ti infastidiscono davvero e puoi permetterti di essere scortese con i segnalatori di bug, poi :

just bounce the emails back to them with a brief message: "Please put this in the bug database. I can't keep track of email."