Perché i sistemi di tracciamento di solito hanno distinti stati "Aperto" e "Riaperto"?
I problemi che sono aperti sono in genere la prima occorrenza di qualunque problema esso sia.
I problemi che sono riaperti sono 1) che si ripresenta e / o 2) non sono stati corretti. Ci possono essere un numero qualsiasi di ragioni per questo - un tasto chiave può spesso essere collegato alla descrizione originale del problema all'utente finale.
Non penso che nessun negozio ragionevole possa usarlo come parametro per giudicare il personale tecnico [da solo], ma è utile come misura per identificare l'efficacia delle risposte e può anche indicare problemi sottostanti che devono essere affrontati.
La mia vecchia società utilizzava quegli stati per tenere traccia di quante volte il tuo problema è andato a "Riaperto" per vedere quanto "cattivo" fosse uno sviluppatore. Hanno pensato che esistesse una correlazione tra il numero di volte in cui un oggetto di lavoro viene "riaperto" e il tuo valore come programmatore.
Non ci lavoro più.
La durata di un bug è spesso:
es.
Qualcuno trova un bug e lo apre nel tracker. Lo sviluppatore lo risolve al meglio con la loro comprensione del problema. Tester esegue nuovamente i test per verificare se la correzione ha funzionato e riapre se possono verificare che non sia stata eseguita. Se la correzione è verificata, il bug è chiuso.
L'altro scenario, è che una correzione da qualche altra parte ha causato una regressione e il bug deve essere corretto di nuovo. Pertanto, viene riaperto.
Potrebbe anche essere più ovvio che il problema richieda maggiore attenzione o maggiore attenzione perché continua a essere un problema dopo che si è ritenuto che il problema fosse stato risolto.
Aperto significa che è un nuovo problema. Meanse ria riaperto era un problema che è stato Aperto- > Clossed e quindi nuovamente aperto.
Perché è stato aperto di nuovo? Forse lo sviluppatore e il tester pensavano che il problema fosse risolto ma non era stato risolto. O forse il problema è stato risolto, ma alcune altre modifiche al codice successive hanno causato il ripetersi del problema. Non importa come, ma un problema riaperto è un brutto segno e quindi è categorizzato in modo diverso.
Il modo in cui lo usiamo qui:
Nuova attività: Creato all'inizio del progetto per mostrare tutto il lavoro che deve essere fatto. È aperto fino a quando qualcuno lo codifica, quindi è risolto. Viene riaperto solo se qualcosa non è stato implementato, o se la funzionalità è cambiata e lo sviluppatore deve tornare indietro e impiegare una buona quantità di tempo a lavorarci sopra.
Bug / Difetto: Aperto da qualcuno nel QA o da un altro addetto al controllo del prodotto operativo complessivo. Se ti viene assegnato un bug, lo risolvi e poi lo risolvono e torna in testing. Se il QA ritiene che non sia stato riparato, lo riaprirà e allega qualsiasi altra informazione a sua disposizione. Il ciclo Risolto / riaperto può andare fino a quando il QA non è stato verificato che il bug è stato corretto, quindi chiudono il ticket.
Quindi, in pratica usi Reopen per dire che un ticket è già stato esaminato e qualcuno ha lavorato su di esso che lo hanno risolto, ma non era così.
È fondamentalmente un tipo di cosa consistenza: un bug (o un problema in generale) è "aperto" se è stato creato da zero. Si "riapre" se è stato creato dopo che è stata eseguita un'elaborazione precedente.
Per uno sviluppatore (o qualcuno che gestisce il problema) non dovrebbe fare alcuna differenza. Un issure è stato sollevato e dovrebbe essere ora elaborato.
Tuttavia, uno stato di "riapertura" distinto può essere ancora utile per una serie di scenari:
In primo luogo, può essere utilizzato come metodo per tenere traccia o meno del processo di assicurazione della qualità. Se il controllo qualità ha fatto tutto correttamente, un bug non dovrebbe mai verificarsi dopo che è stato corretto. Quindi, si può dire che il numero di volte in cui un bug è stato impostato nello stato di "riapertura" è il numero di volte in cui il QA non ha ancora fatto correttamente il suo lavoro. Ciò ovviamente implica che sia stato stabilito un buon processo di controllo qualità e che gli utenti partecipino attivamente al processo e sappiano quando "aprire" e quando "riaprire" un problema.
Un altro uso è che, quando un bug si ripresenta, non è necessario un altro problema, ma è possibile aggiungere le informazioni a un problema già esistente (e quindi mantenere informazioni importanti come la cronologia dei problemi, file aggiuntivi che sono stati caricati, precedente commenti e così via), ma indica ancora "hey, questo è successo di nuovo ).
Una delle ragioni principali per il tracciamento della "riapertura" è che può darti un'indicazione di problemi di routing profondi, piuttosto che semplici sottosopra e supervisione dei dettagli. Se un particolare modulo o parte di funzionalità ha numerosi "ripopens", indica una debolezza che deve essere affrontata. Un gran numero di single apre punti per il lavoro affrettato e / o pratica sciatta.
Leggi altre domande sui tag issue-tracking