Devo registrare un bug che ho scoperto e patchato?

Dipende da chi è il pubblico di un bug report.

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

Elenco non esaustivo dei motivi per registrare comunque:

• Le note di rilascio includono informazioni sui bug risolti (ad alcune soglie che questo bug incontra) - specialmente se c'è una vulnerabilità esposta da questo bug
• La gestione vuole una nozione di "Tempo trascorso bugfixing" / "Conteggio errori 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 che 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, allora sì, crea un bug report. I cicli di rilascio possono spesso essere lunghi e non vuoi che il bug venga segnalato come un nuovo problema mentre lo hai già risolto.

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

Dovresti farlo se si tratta di un bug che potrebbe essere stato segnalato da un cliente. Caso peggiore: correggi il bug, ma nessuno lo sa. Il cliente segnala il bug. Il tuo collega prova a correggere il bug, ma non riesce a riprodurlo (perché lo hai già risolto). Ecco perché vuoi una registrazione del bug.

È anche utile se si eseguono revisioni di codice, in cui solitamente il codice viene scritto per alcune attività e quindi esaminato. In questo caso è meglio avere una correzione dei bug isolata, che potrebbe richiedere di inserire qualcosa nella lista delle attività e poi fare tutto il lavoro.

Questo dipende da diversi fattori.

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

• Il bug è stato parte di una versione ufficiale?
• Il numero di bug / tempo trascorso su di essi viene tracciato in modo specifico?

Possono anche esserci procedure interne da seguire, spesso supportate dai requisiti di una certificazione. Per determinati certificati, è obbligatorio che ogni modifica del codice sia tracciabile in un record in un tracker dei problemi.

Inoltre, a volte anche i bugfix dall'aspetto banale non sono così banali e innocenti come appaiono per la prima volta. Se si associa in modo invisibile un tale bugfix alla consegna di un problema non correlato, e successivamente la bugfix risulta essere problematica, ciò renderà molto più difficile rintracciare, e tanto meno isolare o ripristinare.

Questa domanda può essere veramente risolta solo dal responsabile del tuo progetto o da chi è responsabile del "processo di ticketing".

Ma permettimi di chiedere il contrario: perché dovresti non registrare un bug che hai patchato?

L'unica ragione comprensibile che vedo è che lo sforzo per archiviare il bug report, impegnarsi contro di esso e chiuderlo, è di ordini di grandezza più grandi del tempo per correggere il bug.

In questo caso, il problema non è che il bug sia così facile da risolvere, ma che i documenti richiedano troppo tempo. Non dovrebbe davvero. Per me, l'overhead per creare un ticket Jira è premere c , quindi inserire un breve riassunto a una riga e premere Enter . La descrizione non è nemmeno in testa, dato che posso tagliarla e incollarla nel messaggio di commit, insieme al numero del problema. Alla fine, . c <Enter> e il problema è chiuso. Questo si riduce a 5 tasti premuti in testa.

Non so voi, ma è abbastanza piccolo da renderlo un criterio anche in piccoli progetti per registrare ogni bugfix in questo modo.

Il vantaggio è ovvio: ci sono molte persone che possono facilmente lavorare con un sistema di ticket come Jira, ma non con il codice sorgente; ci sono anche report generati dal sistema di ticket, ma non dalla fonte. Sicuramente vuoi che i tuoi bug risolti siano lì, per conoscere i possibili sviluppi, come un afflusso crescente di piccole correzioni di 1 riga, che potrebbero fornirti informazioni sui problemi del processo o altro. Ad esempio, perché devi fare spesso piccole correzioni di bug (supponendo che capiti spesso)? Può essere che i tuoi test non siano abbastanza buoni? La correzione di bug era una modifica del dominio o un errore di codice? Ecc.

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

Ho scoperto che quello che penso sia un bug è una funzionalità per qualcun altro. Fissando i bug senza rivedere questi bug, potrei creare un bug invece di risolverlo. Inserisci nella segnalazione di bug le linee che cambieresti per correggere il bug e il tuo piano su come dovrebbe essere corretto.

In sintesi: Se questo modulo non è mai stato in produzione, correggi tutti i bug che vedi velocemente e segui le specifiche. Se il modulo è già in produzione, segnala ogni bug come una segnalazione di bug da rivedere prima di risolverlo.

Sì .

Ci sono già alcune risposte che espongono situazioni in cui vale la pena creare un bug report. Alcune risposte. E differiscono.

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

Quindi ora, quando incontri un bug, hai due soluzioni:

• medita se vale la pena aprire un bug report, o no, magari chiedere l'opinione di un collega ... e poi, in alcuni casi, rimpiangere di non averlo fatto perché qualcuno lo sta chiedendo e se tu avessi il rapporto già potresti indicarli a
• crea il rapporto

La creazione del rapporto è più veloce e, se non lo è, automatizzala.

Come automatizzarlo? Supponendo che il tuo tracker supporti gli script, basta creare uno script che puoi chiamare e che userà il messaggio di commit (titolo e corpo) per inviare un bug report e chiuderlo come "implementato" immediatamente, con la revisione del commit associata per il tracciamento.

Ho intenzione di concordare che le altre risposte offrono tutte una buona regola empirica e diversi punti di contatto anche su questo punto, tuttavia penso che qui ci sia solo una risposta davvero sicura.

Chiedi al tuo manager . Bene il tuo manager o in alternativa conduci il 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 in un minuto del corridoio farebbe: "Ehi (capo), se riparo un bug secondario che richiede solo pochi minuti vale la pena fare un biglietto per questo o dovrei solo menzionare nel mio messaggio di commit? " e lo saprai per certo. Tutte le buone pratiche nel mondo sono inutili se questo metodo infastidisce la tua squadra e il tuo manager.