Devo registrare un bug che ho scoperto e patchato?

Suppongo che questa sia una situazione comune: collaudo del codice, scopro un bug, lo risolvo e commetto la correzione del bug nel repository. Supponendo che molte persone lavorino a questo progetto, dovrei prima creare una segnalazione di bug, assegnarla a me stessa e fare riferimento ad essa nel messaggio di commit (ad es. "Correggi bug #XYZ. Il bug era dovuto a X e Y. Risolto da Q e R ")? In alternativa, posso saltare la segnalazione di bug e impegnarmi con un messaggio del tipo "Risolto un bug che causava A quando B. Il bug era dovuto a X e Y. Risolto da Q e R".

Qual è considerata una pratica migliore?

Dipende da chi è il pubblico di una segnalazione di bug.

Se viene esaminato solo internamente dagli sviluppatori, per sapere cosa deve essere risolto, non preoccuparti. È solo rumore a quel punto.

Elenco non esaustivo dei motivi per accedere comunque:

• Le note di rilascio includono informazioni sui bug corretti (a una certa soglia che incontra questo bug), specialmente se c'è una vulnerabilità esposta da questo bug
• La direzione vuole un'idea di "Tempo trascorso a correggere i bug" / "Conteggio dei bug rilevati", ecc.
• I clienti possono vedere lo stato corrente del bugtracker (per vedere se il loro problema è noto, ecc.)
• I tester ottengono informazioni su una modifica per la quale dovrebbero testare.

Direi che dipende dal fatto che il tuo prodotto sia stato rilasciato con il bug o meno.

Se viene rilasciato con il bug che hai trovato, quindi sì, crea un rapporto sui bug. I cicli di rilascio possono spesso essere lunghi e non vuoi che il tuo bug venga segnalato come un nuovo problema mentre lo hai già risolto.

Se il tuo bug non è stato ancora spedito, non seguirei lo stesso percorso. Ora avrai persone che provano a ricreare il tuo bug che non possono perché non è ancora in una versione, essenzialmente sprecando il loro tempo.

Dovresti farlo se si tratta di un bug che avrebbe potuto essere segnalato da un cliente. Caso peggiore: correggi l'errore, ma nessuno lo sa. Il cliente segnala il bug. Il tuo collega tenta di correggere il bug, ma non riesce a riprodurlo in alcun modo (perché lo hai già risolto). Ecco perché vuoi una registrazione del bug.

È anche utile se si eseguono revisioni del codice, in cui il codice viene solitamente scritto per alcune attività e quindi rivisto. È meglio in questo caso avere quella correzione di bug isolata, che potrebbe richiedere di inserire qualcosa nell'elenco delle attività e quindi fare tutto il lavoro.

Questo dipende da diversi fattori.

Sia Pieter B che Caleth ne elencano alcune nelle loro risposte:

• Il bug fa parte di una versione ufficiale?
• Il numero di bug / tempo spesi su di essi viene monitorato in modo specifico?

Possono essere seguite anche procedure interne, spesso supportate dai requisiti di una certificazione. Per alcuni certificati, è obbligatorio che ogni modifica del codice sia rintracciabile in un record in un tracker di problemi.

Inoltre, a volte anche bugfix dall'aspetto banale non sono così banali e innocenti come appaiono per la prima volta. Se si raggruppa silenziosamente un tale bugfix alla consegna di un problema non correlato e il bugfix in seguito si rivela problematico, ciò renderà molto più difficile rintracciare, figuriamoci isolare o ripristinare.

A questa domanda può davvero rispondere solo il responsabile del progetto o chiunque sia responsabile del "processo di ticketing".

Ma lasciami chiedere dall'altra parte: perché non dovresti registrare un bug che hai corretto?

L'unica ragione immaginabile che vedo è che lo sforzo per archiviare la segnalazione di bug, impegnarsi contro di essa e chiuderla, è ordini di grandezza più grandi del tempo per correggere l'errore.

In questo caso, il problema non è che il bug è così facile da risolvere, ma che i documenti richiedono troppo tempo. Non dovrebbe davvero. Per me, l'overhead per creare un ticket Jira sta premendo c, quindi inserendo un breve riepilogo di 1 riga e premendo Enter. La descrizione non è nemmeno sovraccarica, poiché posso tagliarla e incollarla nel messaggio di commit, insieme al numero di problema. Alla fine, . c <Enter>il problema è chiuso. Questo si riduce a 5 tasti premuti dall'alto.

Non so te, ma è abbastanza piccolo da renderlo una politica anche in piccoli progetti per registrare ogni correzione di bug in questo modo.

Il vantaggio è ovvio: ci sono alcune persone che possono facilmente lavorare con un sistema di ticket come Jira, ma non con il codice sorgente; ci sono anche rapporti generati dal sistema di ticket, ma non dalla fonte. Sicuramente vuoi che le tue correzioni di bug siano lì dentro, per conoscere possibili sviluppi, come un flusso in costante aumento di piccole correzioni a 1 riga, che potrebbero fornirti una visione dei problemi di processo o altro. Ad esempio, perché devi fare correzioni di bug così piccole spesso (supponendo che accada spesso)? Può essere che i tuoi test non siano abbastanza buoni? La correzione del bug è stata una modifica del dominio o un errore di codice? Eccetera.

La regola che seguo è che se la sezione su cui stai lavorando non è mai stata rilasciata e non è ancora in esecuzione e nessun utente l'ha mai vista, correggi ogni piccolo bug che vedi rapidamente e vai avanti. Una volta che il software è stato rilasciato ed è in produzione e alcuni utenti lo hanno visto, ogni bug che vedi riceve una segnalazione e viene revisionato.

Ho scoperto che ciò che penso sia un bug è una funzionalità per qualcun altro. Risolvendo i bug senza farli revisionare, potrei creare un bug invece di risolverlo. Inserisci nel bug report quali righe cambieresti per correggere il bug e il tuo piano su come dovrebbe essere corretto.

In breve: se questo modulo non è mai stato in produzione, correggi rapidamente tutti i bug che vedi e segui le specifiche. Se il modulo è già in produzione, segnalare ogni bug come una segnalazione di bug da rivedere prima di correggere.

Sì .

Esistono già alcune risposte che espongono situazioni in cui vale la pena creare una segnalazione di bug. Alcune risposte. E differiscono.

L'unica risposta è che nessuno lo sa. Persone diverse, in momenti diversi , avranno opinioni diverse sulla questione.

Quindi ora, quando si incontra un bug, hai due soluzioni:

• medita se vale la pena aprire una segnalazione di bug, o no, magari chiedi a un collega ... e poi, in alcuni casi, rimpiangi di non averlo fatto perché qualcuno te lo sta chiedendo e se avevi già la segnalazione potresti basta indicarli a quello
• basta creare il rapporto

La creazione del rapporto è più rapida e, in caso contrario, automatizzala.

Come automatizzarlo? Supponendo che il tracker supporti gli script, basta creare uno script che è possibile chiamare e che utilizzerà il messaggio di commit (titolo e corpo) per inviare una segnalazione di bug e chiuderlo immediatamente come "implementato", con la revisione di commit associata per il tracciamento.

Accetterò che le altre risposte offrano tutte buone regole pratiche e molti addirittura toccano questo punto, tuttavia penso che ci sia solo una risposta davvero sicura.

Chiedi al tuo manager . Bene, il tuo manager o in alternativa proietta lead o scrum master ecc. A seconda di come è strutturato il tuo gruppo.

Esistono molti sistemi diversi di buone e cattive pratiche, ma l'unico modo per sapere che stai facendo la cosa giusta per la tua squadra è chiedere.

Qualcosa sulla falsariga di una conversazione di un minuto nel corridoio farebbe: "Ehi (capo), se correggo un bug minore che richiede solo pochi minuti vale la pena farne un biglietto o dovrei semplicemente menzionarlo nel mio messaggio di commit? " e lo saprai per certo. Tutte le buone pratiche al mondo sono inutili se questo metodo infastidisce la tua squadra e il tuo manager.