Passi per mantenere un buon database di bug

Un buon database di bug può avere i seguenti

// Date Time Related

• Emetti la data di scadenza del bug
• Correzione prevista / data della data di risoluzione
• Se risolto, data della data risolta

// Assigned By + To

• Assegnato da (rilevato da)
• assegnato a

// Bug behavior

• Comportamento osservato (bacato)
• Schermata (è possibile)
• Completa i passaggi per riprodurre il bug
• Comportamento previsto

// Priority

• Priorità del bug

// Link, Status and Others

• Collegamento di bug correlati
• Stato del bug
• Se è stato risolto o meno
• Se risolto allora, come risolto con la spiegazione

EDIT: voglio anche raccomandare

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

EDIT: Mi piace @ il commento di jgauffin

• Non aggiustare, Non è un bug, Duplica, Risolto

EDIT: mantiene un buon database di bug

• Matrice di assegnazione della responsabilità

Potrebbero esserci un numero di campi personalizzati che potresti dover registrare, a seconda delle esigenze del progetto. Ho trovato il seguente elenco che potrebbe essere necessario prendere in considerazione:

• Problema DateTime di Bug / Difetto
• Descrizione del bug: passaggi da ricreare.
• Ambiente in cui è stato trovato (Dev, QA, QC, Staging, Prod)
• Schermata del problema
• Chi lo ha registrato (rilevato da)
• A chi è assegnato (assegnato da)
• Severità del bug (basso, medio, alto)
• Risoluzione prevista DateTime
• Triage di stato (proposto, in corso, risolto, chiuso)
• Bug è chiuso DateTime - quando un bug è risolto e chiuso
• Assegnato per essere testato (testato da)

Modifica: la maggior parte delle informazioni comuni che hanno valore da tenere traccia sono ben descritte nei software come Bugzilla . Bugzilla è un bugtracker e uno strumento di test per uso generico basato sul Web originariamente sviluppato e utilizzato dal progetto Mozilla e concesso in licenza con licenza pubblica Mozilla ed è FREE . Vorrei consigliare strongmente come esempio principale e estenderlo alle esigenze del tuo progetto.

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

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

Questo è leggermente più specifico rispetto a quale data / ora il bug è stato scoperto / risolto.

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

Ma c'è di più per mantenere un database dei bug di quanti campi dovrebbe contenere. Devi anche considerare come usi la base.

Cerca di mantenere il numero di bug aperti / non risolti il più basso possibile. Questo può sembrare ovvio, ma potrebbe essere più difficile del previsto, almeno per progetti più grandi. Spesso vedo le persone troppo spaventate per chiudere problemi che non sono riproducibili o in cui le informazioni mancanti non sono mai fornite dal mittente originale del problema. Anche i bug che sono rimasti in giro per sempre e che sono stati visti per l'ultima volta nelle versioni antiche del software non dovrebbero essere lasciati in giro. Ciò fa crescere il database con problemi che possono o non possono essere problemi reali e rallenta lo sviluppo.

Spesso dovresti vedere la cronologia di un bug _ può essere risolto, poi riaperto, poi risolto di nuovo, ecc. Quindi, oltre a ciò che è già stato suggerito, ti consiglierei di avere una tabella separata per tenere traccia della cronologia di un bug ogni volta che viene (ri) aperto. La tabella sarebbe in relazione molti-a-uno con la tabella dei bug e probabilmente avrebbe campi come:

• Data di apertura
• Aperto da
• Data risolta
• Risolto da
• Tempo trascorso
• Come è stato risolto
• ecc.

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

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

Il processo di tracciamento dei bug è tanto importante 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 che il bug esiste?
• Chi può confermare che il bug è stato risolto?
• Chi informa l'utente finale che il bug è stato risolto?

Crea una tabella RACI in modo che tutti i membri del tuo team (compresi gli utenti finali conoscano le loro responsabilità. Combina questo con una corretta registrazione dei dati tecniche e vedrai molto più valore con il minimo sforzo.