È stato aperto un bug, risolto, verificato e chiuso. Un mese dopo, è apparso di nuovo in una versione successiva dopo diverse iterazioni senza alcuna regressione.
Se le caratteristiche del bug sono le stesse, riapri l'ID del bug esistente o apri uno nuovo con un link al bug chiuso?
Le caratteristiche non sono uguali. Il nuovo bug potrebbe avere una ragione di fondo diversa, anche se sembra essere la stessa. Quindi, apri un nuovo bug e indirizzalo a quello vecchio per aiutare lo sviluppatore.
Se è stato verificato e chiuso, ha funzionato per un po 'e poi è apparso di nuovo dopo che qualcosa è stato cambiato, quindi non è lo stesso bug. Potrebbe manifestarsi in modo simile al vecchio bug, ma la causa potrebbe essere diversa. Quindi non è lo stesso bug. Quindi vorrei aprirne uno nuovo, con un link al bug chiuso.
Apri un nuovo bug, sempre. Perché? Supponiamo che risulti identico al precedente bug e che tu abbia rilasciato la correzione per il bug precedente. Le tue note di rilascio documenteranno che "Fix Bug XXX." Dal punto di vista del problema di tracciamento e rendendo più chiare le note di rilascio, è preferibile fare riferimento al nuovo bug "Fix Bug XXX + 1 (che era simile per causa ed effetto a Bug XXX)" piuttosto che per dire "Correzione bug" XXX (Again) "o qualcosa di simile.
In generale, apri un nuovo bug.
Tuttavia, se hai il permesso di fare alcune indagini prima, vorrei controllare la tua cronologia nel codice sorgente .
Se lavori in un ambiente di squadra, qualcuno potrebbe avere un vecchio codice sul proprio sistema (cioè non hanno fatto un Get Latest dopo che la correzione originale è stata archiviata), ha apportato delle modifiche e quindi fatto il check-in senza fare un diff . Cattiva pratica, certo, ma succede "sempre".
Guardando la cronologia dei file in cui è stato corretto il bug, lo confermerà o eliminerà rapidamente come possibilità.
Sono d'accordo con il suggerimento dei post precedenti di aprire un nuovo bug poiché potrebbe non essere la stessa causa principale.
La mia ulteriore raccomandazione sarebbe quella di garantire che tu stia sempre aggiungendo i test di unità e integrazione che coprono il bug, in modo che nelle versioni future tu capisca subito il problema prima che venga distribuito ai tuoi clienti. Niente sembra peggiore per un cliente, quindi è possibile vedere lo stesso bug tornare indietro.
Non la migliore analogia - Solo perché i sintomi di due persone sono uguali, ciò non significa che la malattia / causa della malattia sia la stessa.
Da wikipedia:
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from.....
Un bug è un difetto nel codice e ha sintomi / effetti. Un bug non è il sintomo. Un bug è l'errore nel codice. Solo perché i sintomi sono gli stessi, non significa necessariamente che lo stesso difetto sta causando i sintomi.
La mia comprensione è che dovresti riaprire un bug quando sai per certo che un bug è causato dallo stesso pezzo di codice. Ciò potrebbe accadere quando il codice si comporta correttamente in tutti gli scenari di test / casi di test, ma non in un nuovo caso di test o in un caso di test a cui non avevi pensato prima. Questo tipo di scenario potrebbe non essere comune.
L'altro scenario è che gli stessi sintomi sono causati da nuovi difetti, ovvero nuovi bug in altre parti dello stesso codice o persino in altri sistemi che influiscono su quel codice.
Quindi, la scommessa più sicura è quella di aprire un nuovo bug quando si verificano gli stessi sintomi. Se vedi che lo stesso vecchio codice è responsabile del bug, chiudi il nuovo bug e riapri il vecchio bug. Altrimenti, lascia il nuovo bug e collegalo a quello vecchio.
Leggi altre domande sui tag project-management issue-tracking agile