Come imponi o mantieni la qualità delle segnalazioni di bug nel tuo bug tracker?

Question

Segnalazioni di bug di alta qualità sono essenziali per un tracciamento efficace dei bug: in un mondo ideale tutte le segnalazioni di bug conterrebbero informazioni essenziali come la versione del software interessata e una descrizione passo passo su come riprodurre il bug.

In realtà, però, i bug segnalati possono variare molto in termini di qualità.Potrebbero essere on-liner ("la funzionalità X non funziona, risolvila!"), richieste di funzionalità, PEBKAC o incomprensibili.

Come imponi o mantieni la qualità delle segnalazioni di bug nel tuo bug tracker per rimanere efficace?

Answer 1

Sono d'accordo con Jon Limjap: il tuo personale addetto al controllo qualità deve essere sufficientemente competente da pubblicare segnalazioni di bug appropriate, data la giusta formazione di base e linee guida.Tuttavia, ci sono modi per imporre e incoraggiare una migliore segnalazione dei bug:

• La maggior parte dei software di tracciamento dei bug hanno un modo per contrassegnare alcuni campi della segnalazione di bug come obbligatori, in modo che chi segnala debba effettivamente scegliere il valore appropriato per creare con successo il bug
• Di solito c'è la possibilità di includere un modello di base per la segnalazione di bug, qualcosa di simile a

Scenario:

Risultati aspettati:

Risultati attuali:

Osservazioni:

• Puoi (e dovresti) fornire uno strumento di segnalazione dei bug che verrà eseguito sulla macchina problematica, raccogliere le informazioni rilevanti e comprimerle in un file di archivio (e magari posizionarlo sul desktop).Quindi chiedi al tuo staff di eseguirlo ogni volta che riscontrano un bug che desiderano segnalare e di allegare l'archivio al bug.Questo strumento dovrebbe essere facile da usare (basta eseguire un eseguibile) in modo da poter allegare le informazioni diagnostiche a qualsiasi bug senza dover pensare se è rilevante o meno.Questo strumento è solitamente molto utile anche con i clienti.
• Ultimo ma non meno importante: "educazione, educazione, educazione".Le persone imparano meglio dall'esperienza: assicurati solo che ogni volta che qualcuno apre un bug senza le informazioni adeguate incluse, la persona che gestisce il bug vada a parlare con chi ha aperto il bug e spieghi cosa manca e perché è importante.

Queste sono pratiche che utilizziamo con successo nel mio attuale posto di lavoro e credo che siano abbastanza universali per adattarsi alla maggior parte degli ambienti di lavoro.

Answer 2

Pensavo che la qualità della segnalazione di bug fosse equivalente.Lo penso ancora...i bug che segnalo contengono informazioni molto più utili di quelle inserite dal QA o dalle operazioni.Tuttavia, sono arrivato ad ammirare il modello di FogBugz.È estremamente semplice inserire un bug.Anche solo sapere che è presente una condizione di errore è utile, anche se non sono disponibili molte informazioni di supporto.Inoltre, gli utenti hanno la sensazione che qualcosa venga fatto.

Answer 3

Scrivi un tutorial valido ma non troppo lungo sull'utilizzo del tracker e su cosa è richiesto per ciascun campo.Crea un esempio di riferimento per scopi generali che gli altri possano utilizzare se rimangono bloccati.

Ho una copia di riferimento per modificare le pagine del manuale di Docbook e, utilizzandola ripetutamente, conosco già a memoria la maggior parte della sintassi.

Answer 4

Dipende se si parla di una revisione QA chiusa o di una beta pubblica.

Se si tratta di una beta pubblica non è consigliabile consentire agli utenti di modificare direttamente l'elenco dei bug.Qualcuno dovrebbe essere incaricato di aggregare commenti e segnalazioni degli utenti e di discernere quali sono bug effettivi e quali sono duplicati e che forniscono una sorta di indizio su come replicarli.

Se questo, tuttavia, è un bug pubblicato dal tuo legittimo personale di QA, hai un problema di competenza nei confronti dei tuoi dipendenti.È necessario impostare linee guida adeguate su come segnalare i bug, in particolare per ottenere passaggi di replica diretti.

Answer 5

Domanda difficile.Proverei a vedere se il sistema ha un modo per imporre l'inserimento di determinati campi richiesti, proverei a far sì che tutti i bug critici si presentino ai tuoi occhi in qualche modo (e-mail, RSS) in modo da poter balzare rapidamente, ma soprattutto quello il tuo team è consapevole dello standard di qualità e lo rispetta, le linee guida sono pubblicate e pubbliche, quel genere di cose.

Supponendo che sia la tua squadra:Se puoi avere una certa struttura che viene utilizzata ogni volta in un campo commenti, di ciò che ci si aspetta quando viene inserito, allora anche questo sarebbe positivo - ancora meglio se il tuo software ha uno schema di note predefinito in cui puoi definire quella struttura su un modulo vuoto.

In una certa misura, però, dipende dall'individuo, deve essere consapevole che fa parte degli standard di comunicazione, è previsto come requisito lavorativo e che è responsabile nei confronti di ogni altro membro del team, perché le altre persone non dovrebbero Non essere in grado di dar loro la caccia per scoprire ulteriori dettagli se ciò potesse essere evitato.

Soprattutto perché il tempo di risposta per la correzione dei bug su elementi con priorità inferiore potrebbe essere un po' di tempo e le persone sono destinate a dimenticare i dettagli.

Supponendo che siano utenti:Non è possibile in larga misura, ma proverei, se possibile, a porre domande su qualsiasi forma in modo che le persone possano capire.

Non interamente su questo argomento, ma in un certo senso "come poni le domande", c'è questo post sul blog di 37 Signals - testo del collegamento

Anche se devi avere un altro modulo che pone le domande visibili ai tuoi utenti, che alimenta principalmente i dati al programma bug, lo farei solo per porre le domande giuste.

Quale prodotto?Quale versione (le immagini mostrano come trovarla)?Sarebbe utile includere un dump dello schermo, se potessero aprire il programma e premere un pulsante per inviare automaticamente un file di registro, se ha impedito loro di eseguire ulteriore lavoro, se ha perso le modifiche, ecc.

Per gli utenti probabilmente si tratta più di come poni le domande e di far loro sapere che hai bisogno di una risposta ad alcune o quali troverai più utili, quindi probabilmente otterrai risposte migliori.

Answer 6

Usa qualcosa di simile UserVoice per consentire agli utenti finali di segnalare bug e richieste di funzionalità.Le voci del bug tracker dovrebbero davvero essere interne: sono troppo tecniche per gli utenti finali e inoltre, IMHO, espongono un po' troppo il funzionamento interno.