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 cattura dello schermo che mostra chiaramente l'errore. Ma il report ha quasi un mese di vita e il bug non può più essere riprodotto nel nostro ambiente di produzione.
Come dovrei rispondere al cliente e all'utente?
Ripristina il tuo ambiente di sviluppo nella versione in cui è stato rilevato il bug e verifica che il bug sia presente.
Se è presente, puoi esaminare il bug e assicurarti che la versione corrente non ce l'abbia. Quindi chiudi il bug report 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 illustrate in molte altre domande saranno utili (Grazie Thomas per l'elenco iniziale):
Immagino che tu abbia veramente fatto tutto il possibile per riprodurre il bug, ma non ci riesci.
In un caso come questo spesso è meglio aggiungere del codice attorno all'area dell'applicazione che non è riuscito a registrare il lavoro in corso, in modo che speriamo di avere più dati da lavorare se succede di nuovo. Pensa attraverso quali informazioni devi avere che attualmente non hai a disposizione. Ad esempio, forse si verifica solo quando viene inviato un particolare set di parametri di input e quindi li registri ogni volta che viene eseguito il processo. Controlla però con il tuo capo prima di farlo, a seconda dell'importanza del bug e della frequenza con cui si è verificato, potrebbe non voler passare il tempo per farlo.
Poi vai dalla persona che ha segnalato il bug (puoi farlo nell'applicazione di tracciamento dei bug se ne hai uno, non devi andare di persona) e dire che non sei riuscito a riprodurre il bug ma hai aggiunto alcune registrazioni aggiuntive per ottenere maggiori dettagli su ciò che il processo sta facendo nel caso in cui l'errore si ripresenti. Quindi chiudi il bug.
Se non è possibile eseguire ulteriori registrazioni. riferisci semplicemente che il bug non è riproducibile e che se lo incontrano di nuovo, questa è l'informazione che ti servirà per riprodurlo e dirgli cosa ti serve. Spesso chiediamo loro di dirci esattamente quali parametri di input stanno inserendo quando hanno ricevuto l'errore. Solo avere una schermata dell'errore aiuta, ma sapere esattamente quali passi stanno prendendo e quali informazioni hanno provato a utilizzare nel momento in cui si è verificato l'errore è più utile. Quindi in pratica stai rimettendo l'onere su di loro per darti più informazioni quando segnalano l'errore se si verifica nuovamente.
Nel tuo bug tracker, assicurati di spiegare quali passi hai provato, in modo che se il bug si ripresenta, la persona che la gestisce avrà uno sfondo in quello che è stato fatto prima.
Le borse non riproducibili sono le peggiori! Potrebbe essere stato risolto nel frattempo, o potrebbe essere ancora lì, ma è sporadico oppure i passaggi per la riproduzione non sono sufficientemente specificati. Devi fare un giudizio su quanto sia alto il rischio del bug, e su quanto ti espanderai per studiarlo. Stai facendo 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 sai che sono state apportate modifiche che potrebbero aver causato l'errore nel bug involontariamente, potrebbe essere accettabile chiudere il bug con la nota che non è riproducibile e si presuppone che sia stato corretto.
Se sei più preoccupato, potresti fare alcune teorie su ciò che ha causato il bug in primo luogo e controllare il log delle modifiche e la cronologia delle fonti per vedere se riesci a individuare dove si sono risolte.
Per un bug più serio, dovrai ripristinare la sorgente al punto dell'ultima versione, quindi provare a riprodurla. Se si riproduce correttamente, è possibile scrivere dei test per assicurarsi che vengano corretti in successivi commit.
Leggi altre domande sui tag issue-tracking defect