Riapertura dell'insetto vs. nuovo


55

È stato aperto, corretto, verificato e chiuso un bug. 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 bug esistente o ne apri uno nuovo con un link al bug chiuso?

Risposte:


86

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.


23
+1 ci sono molte malattie diverse con diversi trattamenti che condividono sintomi comuni .
FrustratedWithFormsDesigner

Sarebbe corretto dedurre che se il bug dimostrasse di avere la stessa causa, lo riapriresti?
KMoraz,

@KMoraz: Penso di sì, ma è solo qualcosa da considerare dopo che l'indagine dimostra che è la stessa identica causa. Poiché i sintomi sono scomparsi per un po ', è improbabile che si tratti dello stesso identico bug, sebbene possa essere un bug introdotto in una parte diversa del sistema, ma codificato nello stesso modo in cui è stato codificato il bug originale e causando quindi sintomi simili.
FrustratedWithFormsDesigner

1
@KMoraz Direi di no. Supponiamo che sia stato corretto in 1.0, 1.1 non lo avesse, ma riapparve in 1.2. A meno che il tracker dei problemi non ti consenta di associarlo contemporaneamente alle versioni server, perderai la cronologia trovata e risolta in 1.0. Basta aprire un nuovo bug.
Andy,

1
@Andy Non credo che cambi nulla, ma forse l'1 è stato e nessuno se ne è accorto ...
joshuahedlund

35

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.


16

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.


2
Citando gli ID dei bug nelle note della patch è solo ... molto ostile.
Thomas Bonini,

3
@krelp È utile quando lavori con un fornitore per risolvere un problema e puoi tenere traccia dell'ID bug che hai ricevuto con un ID bug nelle note di rilascio.
Darryl Braaten,

1
@Krelp Mi chiedevo perché sia ​​una cattiva idea, quindi ho chiesto qui: programmers.stackexchange.com/questions/142258/… Forse hai qualche input in merito? :)
Travis Northcutt

Questo è un buon punto
KMoraz

4

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à.


1
"(cioè, non hanno fatto Get Get Latest dopo aver effettuato il check-in della correzione originale), hanno apportato modifiche e poi hanno fatto il check-in senza fare una differenza" ... se ciò accade, il tuo sistema di controllo del codice sorgente è rotto
JoelFan

@JoelFan - non necessariamente. A volte l'unione automatica non funziona correttamente e talvolta l'unione manuale non funziona correttamente. Oppure, potrebbe essere solo il caso che abbiano perso il cambiamento quando hanno fatto il diff, ecc. Tutto quello che sto dicendo è che questo odora di errore umano e un controllo di 2 minuti della cronologia del controllo del codice sorgente può salvare un sacco di problemi.
Wonko the Sane,

1
Controllare la storia vale comunque ... perché se il tuo sistema di controllo del codice sorgente è rotto, vuoi saperlo.
mjfgates,

2
Se ciò accade all the time, non è l'SCM a essere rotto, è il tuo team di sviluppo ...
Daenyth,

1

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.


1

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.