I passaggi per mantenere un buon database di bug

Il mantenimento del database dei bug è importante per ogni progetto. Sono abituato a memorizzare i seguenti nel database dei bug

• Data di emissione ora
• A chi è assegnato
• Che sia stato risolto o meno
• Se risolto, risolto ora data

Sono sufficienti per mantenere un buon database di bug?

Un buon database di bug può avere i seguenti

// Data Ora correlata

• Data di emissione ora del bug
• Data prevista di correzione / risoluzione prevista
• Se risolto, risolto ora data

// Assegnato da + A

• Assegnato da (rilevato da)
• Assegnato a

// Comportamento di bug

• Comportamento osservato (buggy)
• Schermata (è possibile)
• Passaggi completi per riprodurre il bug
• Comportamento atteso

// Priorità

• Priorità del bug

// Link, Status e altri

• Collegamento di bug correlati
• Stato del bug
• Che sia stato risolto o meno
• Se risolto, risolto con spiegazione

EDIT: voglio anche raccomandare

• In quale revisione / ramo è stato scoperto il bug
• In quale revisione / ramo è stato corretto il bug

EDIT: Mi piace il commento di @ jgauffin

• Non risolverà, non un bug, duplicato, risolto

EDIT: mantiene anche un buon sistema di database di bug

• Matrice di assegnazione di responsabilità

Potrebbe essere necessario un numero di campi personalizzati che potrebbe essere necessario registrare, a seconda delle esigenze del progetto. Ho creato il seguente elenco che potresti dover considerare anche:

• Problema DateTimedi errore / difetto
• Descrizione del bug - passaggi per ricreare.
• Ambiente in cui è stato trovato (Dev, QA, QC, Staging, Prod)
• Schermata del problema
• Chi l'ha registrato (rilevato da)
• A chi è assegnato (assegnato da)
• Gravità del bug (bassa, media, alta)
• Risoluzione prevista DateTime
• Triage statale (proposto, in corso, risolto, chiuso)
• Bug è chiuso DateTime- quando un bug viene risolto e chiuso
• Assegnato per essere testato (testato da)

Modifica: la maggior parte delle informazioni comuni che hanno un valore da tenere traccia sono ben descritte in software come Bugzilla . Bugzilla è un bugtracker e strumento di test generico basato sul Web originariamente sviluppato e utilizzato dal progetto Mozilla e concesso in licenza in base alla Licenza pubblica Mozilla - ed è GRATUITO . Consiglio vivamente di prenderli come esempio principale e di estenderlo alle esigenze del progetto.

La maggior parte dei campi utili sembra essere già stata coperta da altre risposte, ma alcuni che trovo utili sono:

• In quale revisione / ramo è stato scoperto il bug.
• In quale revisione / ramo è stato corretto.

Questo è leggermente più specifico rispetto alla data / ora in cui il bug è stato scoperto / corretto.

Se il tuo software funziona su più piattaforme (sistema operativo o hardware), potresti anche voler un campo che elenca le piattaforme in cui si verifica il bug.

Ma c'è di più nel mantenimento di un database di bug rispetto ai campi che dovrebbe contenere. È inoltre necessario considerare come utilizzare la base.

Cerca di mantenere il numero di bug aperti / non risolti il ​​più basso possibile. Questo può sembrare ovvio, ma può essere più difficile del previsto, almeno per progetti più grandi. Vedo spesso le persone che hanno troppa paura di chiudere problemi che non sono riproducibili o in cui la mancanza di informazioni non è mai fornita dal soggetto che ha presentato il problema. Inoltre, i bug che sono rimasti in giro per sempre ed è stato visto l'ultima volta nelle versioni antiche del software non dovrebbero essere lasciati in giro. Questo fa crescere il database con problemi che possono o meno essere problemi reali e rallenta lo sviluppo.

Avresti spesso bisogno di vedere la cronologia di un bug _ potrebbe essere risolto, quindi riaperto, quindi risolto di nuovo, ecc. Quindi, oltre a quanto è già stato suggerito, ti consiglio di avere una tabella separata per tenere traccia della cronologia di un bug ogni volta che viene (ri) aperto. La tabella sarebbe in una relazione molti a uno con la tabella dei bug e probabilmente avrebbe campi come:

• Data di apertura
• Aperto da
• Data risolta
• Risolto da
• Tempo impiegato
• Come è stato risolto
• eccetera.

Potresti anche aver bisogno di una tabella simile per tracciare a chi e quando il bug è stato (ri) assegnato, specialmente se lavori in una grande squadra.

Ti suggerisco anche di dare un'occhiata ai sistemi esistenti. IMHO Jira è uno dei migliori sistemi di localizzazione dei problemi. Ha funzionalità molto ricche e potresti usarne alcune come guida per il tuo sistema.

Il processo di tracciamento dei bug è importante tanto quanto i dati. Prova a pensare anche a quanto segue:

• In che modo gli utenti segnalano il bug?
• Chi inserisce il bug nel repository?
• Chi può confermare l'esistenza del bug?
• Chi può confermare che l'errore è stato risolto?
• Chi informa l'utente finale che il bug è stato risolto?

Costruisci un grafico RACI in modo che tutti i membri del tuo team (compresi gli utenti finali conoscano le proprie responsabilità. Combinalo con le tecniche di immissione dei dati corrette e vedrai un valore molto maggiore con il minimo sforzo aggiuntivo.