Risposte:
Le caratteristiche non equivalgono alle cause. Il nuovo bug potrebbe avere un motivo di fondo diverso, anche se sembra essere lo stesso. Quindi, apri un nuovo bug e puntalo 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, allora non è lo stesso bug. Può manifestarsi allo stesso modo del vecchio bug, ma la sua causa potrebbe essere diversa. Quindi non è lo stesso bug. Quindi vorrei aprirne uno nuovo, con un collegamento al bug chiuso.
Apri un nuovo bug, sempre. Perché? Supponiamo che risulti identico al bug precedente e che hai rilasciato la correzione per il bug precedente. Le note di rilascio documenteranno che "Correggi bug XXX". Dal punto di vista del rilevamento dei problemi e del chiarimento delle note di rilascio, è preferibile fare riferimento al nuovo bug "Correggi bug XXX + 1 (che era simile in causa ed effetto al bug XXX)" piuttosto che dire "Correggi bug XXX (Again) "o qualcosa di simile.
In generale, aprire un nuovo bug.
Tuttavia, se ti è permesso fare qualche indagine prima, controllerei la tua cronologia nel codice sorgente .
Se lavori in un ambiente di squadra, qualcuno potrebbe avere un vecchio codice sul proprio sistema (ovvero, non ha fatto Get Get Latest dopo aver effettuato il check-in della correzione originale), apportato modifiche e quindi registrato senza fare una differenza. Cattiva pratica, certo, ma succede "tutto il tempo".
Osservare la cronologia dei file in cui è stato corretto il bug confermerà o eliminerà rapidamente questa possibilità.
all the time
, non è l'SCM a essere rotto, è il tuo team di sviluppo ...
Sono d'accordo con il suggerimento dei precedenti poster di aprire un nuovo bug poiché potrebbe non essere la stessa causa principale.
La mia ulteriore raccomandazione sarebbe quella di assicurarti di aggiungere sempre test unitari e di integrazione che coprano il bug in modo che nelle versioni future affronti subito il problema prima che venga risolto dai tuoi clienti. Nulla sembra peggio per un cliente, quindi vedere lo stesso bug tornare.
Non la migliore analogia - Solo perché i sintomi di due persone sono gli stessi, ciò non significa che la malattia / causa della malattia sia la stessa.
Da Wikipedia:
Un bug del software è un errore, un difetto, un errore o un errore in un programma per computer o in un sistema che causa un risultato errato o imprevisto o un comportamento involontario. La maggior parte dei bug deriva da .....
Un bug è un difetto nel codice e ha sintomi / effetti. Un errore non è il sintomo. Un errore è l'errore nel codice. Solo perché i sintomi sono gli stessi, ciò non significa necessariamente che lo stesso difetto stia causando i sintomi.
La mia comprensione è che dovresti riaprire un bug quando sai per certo che un bug è causato a causa dello stesso codice. Ciò può 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 caso di test a cui non si è 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 influenzano quel codice.
Quindi, la scommessa più sicura è aprire un nuovo bug quando si verificano gli stessi sintomi. Se vedi che lo stesso vecchio codice è responsabile del bug, quindi chiudi il nuovo bug e riapri il vecchio bug. In caso contrario, lascia che il nuovo bug rimanga e collegalo a quello vecchio.