Come affrontare un bug che sembra essersi risolto? [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 4 anni fa .

Sono uno sviluppatore di applicazioni web per un sistema interno. Un utente segnala che c'è un bug.

Il bug era che alcune parole non potevano essere visualizzate. Il rapporto contiene una schermata che mostra chiaramente il bug. Ma il rapporto ha quasi un mese e il bug non può più essere riprodotto nel nostro ambiente di produzione.

Come devo rispondere al cliente e all'utente?

issue-tracking defect

— Ben Cheng
fonte

Abbiamo alcune domande correlate qui sui programmatori: eliminare un bug se non esiste un caso di test riproducibile? Come isolare i bug difficili da riprodurre? Come eseguire il debug del codice nel modo più efficace? Bug inspiegabili? Cosa fare con i bug che non vengono riprodotti?

— Thomas Owens

Scopri come renderlo ripetibile.

— Wyatt Barnett,

Quanto tempo puoi permetterti questa indagine? Quanto è stato critico il bug e i suoi effetti negativi? Se le risposte sono molto ridotte e trascurabili, direi che contrassegnarlo come riparato con una nota delle circostanze in cui non è realmente risolto e aspettare che ritorni è un uso perfettamente accettabile delle risorse della tua azienda.

— Newtopian,

Questo richiede solo una risposta piuttosto standard: " Caro [utente], il problema con X che hai segnalato su Yth sembra essere stato risolto con l'ultima versione di Z. Ti preghiamo di contrassegnare il problema come risolto se è davvero così In caso contrario, ti preghiamo di inviarmelo di nuovo con i dettagli su come l'hai incontrato. "

— Lilienthal,

@Lilienthal Solo perché un bug non può essere riprodotto non significa che sia stato risolto. Non sai nemmeno che c'è stata una nuova versione nell'ultimo mese.

— paparazzo,

Risposte:

Ripristina il tuo ambiente di sviluppo alla versione in cui è stato rilevato il bug e verifica che il bug sia presente.

Se è lì, puoi esaminare il bug e assicurarti che la versione corrente non lo abbia. Quindi chiudere la segnalazione di bug con il commento che una modifica non correlata ha risolto. Aggiungi un test di regressione, se necessario.

Se non riesci a riprodurre il bug in quella versione, le strategie descritte in molte altre domande qui saranno utili (Grazie Thomas per l'elenco iniziale):

— maniaco del cricchetto
fonte

Nella mia esperienza, la maggior parte dei team seleziona l'opzione "impossibile riprodurre" nel sistema di ticketing e la chiude. Testare il codice "then" e "now" per assicurarsi che il problema fosse presente e non lo sia più sembra una soluzione migliore. Ma richiede anche più tempo rispetto a dire "impossibile riprodurre" e chiuderlo, quindi potrebbe non essere un'opzione per ogni errore.

— Paul J Abernathy,

Dipende da quanto sia grave il bug. Se è solo uno scherzo del layout, allora davvero non è possibile ripetere il timbro ed essere fatto, ma se potrebbe essere più sinistro allora poche ore per finire con un test di regressione possono valerne la pena.

— maniaco del cricchetto

@ratchetfreak In alternativa, dipende dalla gravità di questo particolare cliente. Se stanno finanziando da soli i tuoi stipendi, forse vale la pena di umorizzarli ;-)

— Cort Ammon - Ripristina Monica il

I problemi che si risolvono da soli ritornano da soli.

— Pete Becker,

È tutta una questione di carico di lavoro. Se hai un bug che era riproducibile un mese fa e non lo è più, e un altro bug che è riproducibile ora , correggi quello che è riproducibile ora per primo. Se mai arrivi in uno stato in cui sei totalmente annoiato, allora puoi indagare. E quando il problema ritorna da solo, ovviamente è un bug riproducibile e inizi a risolverlo :-)

— gnasher729

Presumo che tu abbia fatto davvero tutto il possibile per riprodurre il bug ma non puoi.

In un caso come questo è spesso meglio aggiungere un po 'di codice nell'area dell'applicazione che non è riuscito a registrare il lavoro svolto, in modo che si speri di avere più dati per lavorare se si ripete. Pensa a quali informazioni devi avere che al momento non hai a disposizione. Ad esempio, forse si verifica solo quando viene inviato un determinato set di parametri di input e quindi li registri ogni volta che il processo viene eseguito. Verificare con il proprio capo comunque prima di farlo, a seconda dell'importanza del bug e della frequenza con cui si è verificato, potrebbe non voler passare il tempo per farlo.

Quindi vai alla persona che ha segnalato il bug (puoi farlo nell'applicazione di tracciamento dei bug se ne hai uno, non devi andare di persona) e dici che non sei stato in grado di riprodurre il bug ma ne hai aggiunto alcuni registrazione per ottenere maggiori dettagli su cosa sta facendo il processo nel caso in cui si ripresenti il bug. Quindi chiudere il bug.

Se non riesci a eseguire registrazioni aggiuntive. segnala semplicemente che il bug non era riproducibile e che se lo incontrano di nuovo, queste sono le informazioni che ti serviranno per riprodurlo e dire loro ciò di cui hai bisogno. Spesso chiediamo loro di dirci esattamente quali parametri di input hanno inserito quando hanno riscontrato l'errore. Il solo fatto di avere una schermata dell'errore aiuta, ma è più utile sapere esattamente quali passi stavano intraprendendo e quali informazioni hanno cercato di utilizzare nel momento in cui si è verificato l'errore. Quindi in sostanza stai rimettendo l'onere su di loro per darti maggiori informazioni quando segnalano l'errore se si verifica di nuovo.

Nel tuo bug tracker, assicurati di spiegare quali passaggi hai provato, in modo che se il bug si ripresenta, la persona che lo gestisce avrà un po 'di background in ciò che è stato fatto prima.

— HLGEM
fonte

I sacchetti non riproducibili sono i peggiori! Potrebbe essere stato corretto nel frattempo, oppure potrebbe essere ancora lì, ma è sporadico o i passaggi per la riproduzione non sono specificati in modo sufficiente. Devi fare un appello al giudizio su quanto è alto il bug e su quanto ti espanderai indagando. Stai creando un gestore di ricette online o un software di controllo dello sterzo per missili nucleari?

Se si tratta di un bug a basso impatto e si sa che sono state apportate modifiche che potrebbero aver portato alla correzione involontaria del bug, potrebbe essere accettabile chiudere il bug con la nota che non è riproducibile e si presume che sia stato corretto .

Se sei più preoccupato, potresti fare alcune teorie su ciò che ha causato il bug in primo luogo e guardare attraverso il registro delle modifiche e la cronologia delle fonti per vedere se riesci a individuare dove sono state risolte.

Per un bug più grave, dovrai ripristinare la sorgente fino al punto dell'ultima versione, quindi provare a riprodurre. Se la riproduzione viene eseguita correttamente, è possibile scrivere test per assicurarsi che sia risolto in commit successivi.

— JacquesB
fonte