Gli sviluppatori dovrebbero inserire errori nel sistema di tracciamento dei bug?

Se scopri un bug, non riesco a pensare a nessuna buona ragione non per inserirlo nel sistema di tracciamento dei bug, che tu lo aggiusti o meno. Dopo tutto, questo è il sistema di tracciamento dei bug.

In alcuni casi potrebbe essere più sensato segnalarlo a una persona con QA che ha più esperienza nel trattare con il sistema, ma in ogni caso il bug dovrebbe essere rintracciato.

È possibile che ci possa essere una qualche ragione, valida o no, che gli sviluppatori non debbano inserire bug. Una possibile ragione potrebbe essere che il sistema di tracciamento dei bug è visibile agli estranei, e avere troppi bug segnalati sembra cattivo. Questa è una pessima ragione, che dovrebbe essere affrontata in un altro modo che permetta comunque di tenere traccia degli errori. Chiedi al tuo capo.

(Naturalmente se c'è un bug nel codice su cui stai ancora lavorando, e non compare in tutto ciò che è stato rilasciato, non c'è bisogno di rintracciarlo nel sistema, sebbene un commento TODO nella fonte il codice potrebbe essere una buona idea. Per prendere un caso estremo, "Questo codice non verrà compilato perché non ho ancora digitato il punto e virgola alla fine di questa riga" non è un bug segnalabile.)

Per quanto riguarda il motivo per cui altri sviluppatori non inseriscono bug, dovrai chiedere loro. Probabilmente dovrebbero.

Devi inserire i bug nel sistema di tracciamento dei bug in entrambi i casi:

• quando l'errore riguarda direttamente il codice su cui stai lavorando,

• quando l'errore riguarda il codice su cui non stai lavorando in questo momento o la parte su cui un altro sviluppatore funziona.

Questo è essenziale, dal momento che il sistema di tracciamento dei bug è fatto per ... tracciare bug. Ogni bug Se scopri qualcosa di sbagliato, non limitarti a risolverlo. Documentalo attraverso il sistema di tracciamento dei bug. Quando in seguito, un cliente che esegue una versione precedente del software segnalerà un bug che è un duplicato esatto, sarà possibile collegarlo al report. Se non hai nulla a cui collegarti, perdi tempo (o il tuo collega) a cercare il bug nelle revisioni precedenti, quindi cerca di risolverlo e infine scopri che il bug è già stato risolto magicamente.

Questo spiega anche perché i freelance devono usare sia il controllo della versione che il sistema di tracciamento dei bug: questi due strumenti non sono solo per i team.

Non vi è alcun motivo valido per non inserire un difetto nel sistema di tracciamento dei difetti. Gli unici posti in cui ho visto correzioni di bug applicate senza tracciamento sono perché il processo era fondamentalmente rotto. Se questo è il caso, correggi il processo.

I motivi per non entrare sono:

• Il processo misura e punisce in base al rapporto sui difetti - non riferire, non essere punito. In questo caso lascia l'organizzazione
• Il processo è un onere: ci vuole troppo tempo e fatica per inserire un difetto e arrivare al punto di risolverlo. Il processo dovrebbe essere modificato per consentire agli sviluppatori di tracciare rapidamente un bug leggero attraverso il processo di triage / accept / fixed.
• Alcuni sviluppatori sono pigri / sciatti / hacker a cui non importa quale possa essere l'impatto delle cose che fanno sugli altri. Recluta sviluppatori professionisti.
• Sono una one man band, non capisco il punto. Vai a lavorare per una band di 2 uomini e lo farai ....

Risolvere il bug subito è probabilmente una cattiva idea. In primo luogo, qualcun altro potrebbe lavorare sulla stessa correzione, risultando in uno sforzo duplicato e inoltre, in base alla metodologia di sviluppo che si sta seguendo, dare la priorità a ciò su cui lavorare successivamente (correggere un bug o implementare una nuova funzionalità) è più di un decisione di gestione quindi una decisione di sviluppo.

La decisione non è chiara e comporta dei compromessi.

(alcuni) PROS

Il tracciamento dei bug è essenziale per la comunicazione, in particolare per i team di grandi dimensioni. Uno dei migliori vantaggi di avere più occhi sul codice è la capacità di rilevare i problemi in precedenza, e tale beneficio è perso se i bug non vengono registrati o tracciati mentre si sta sviluppando.

• Spesso i bug si risolvono più facilmente mentre ci si trova già in una parte del codice, lavorando per capirlo.
• Anche nelle squadre più piccole, c'è molto beneficio per essere saggi dal punto di vista del morale essendo in grado di elencare i bug e progredire nel risolverli - a volte il beneficio morale è cruciale anche nei progetti one man.
• Il rilevamento accurato dei bug può essere molto difficile dopo il fatto - vedere un bug nel codice può far risparmiare un sacco di lavoro in futuro al detective, cercando di capire dove si è originariamente verificato il problema.
• È positivo per lo sviluppo generale come sviluppatore prestare attenzione ai bug mentre li vedi, e abituarsi a migliorare / ripulire / leggere il codice in modo critico

La registrazione dei bug come li trovi è, generalmente parlando, una buona abitudine da avere.

(alcuni) CONS

L'inserimento di bug in un sistema di tracciamento dei bug può essere oneroso e richiedere molto tempo, e può essere davvero dannoso per il lavoro di sviluppo, più spesso quando si lavora in team di grandi dimensioni. Ci si può aspettare che:

• controlla se la tua voce è un duplicato prima di entrare (questo potrebbe anche essere implicito, è scoraggiante inserire il bug nella coda solo per averlo chiuso)
• fornire casi di test ripetibili per il tuo rapporto
• accetta le interruzioni successive con domande sui dettagli del bug, per accettare / verificare una correzione quando viene scritta
• pensa a informazioni non correlate che vengono spesso raccolte nei sistemi di tracciamento dei bug, ad esempio quale prodotto è più probabile, la priorità del bug, ecc ...

A volte il monitoraggio dei bug non è l'uso più efficiente del tuo tempo.

Questi sono due principi generali che possono essere difficili da bilanciare: trovare una buona strategia è un po 'un'arte. In situazioni come queste, penso che sia meglio adottare un'euristica flessibile, che modifichino come richiesto per un dato progetto, team, ambiente di lavoro e le tue abilità generali. La mia strategia di solito segue un modello come approssimativamente come segue:

• Registra sempre i problemi come li vedi durante la giornata, da qualche parte. Forse su un appiccicoso, forse in un file a lato. Forse tutto ciò che si registra è un nome di file e un numero di riga, forse di più. Non lasciare che il problema interrompa troppo la tua linea di pensiero attuale.

• Prenditi il tempo all'inizio di ogni nuovo giorno lavorativo, come parte del tuo warm-up per il lavoro, per gestire gli sticky. Prendo 10-15 minuti per esaminare la mia lista di problemi rilevati dal giorno precedente e fare il più veloce dei seguenti:

  • Correggere il problema e eseguirne il commit (probabilmente per correzioni o errori di digitazione). Se non ti è permesso di commettere senza una segnalazione di bug, crea un side-project per piccoli commit. Quando si accumulano abbastanza correzioni nel progetto parallelo, prendi le poche ore necessarie per documentarle e impegnarti.
  • Registra il problema in un sistema di tracciamento dei bug (per problemi ovvi che richiedono più tempo per risolverlo, ma senza un sovraccarico oneroso)
  • Registra il problema in un documento "da guardare quando non occupato" (di solito aggiungo un commento "// TODO - questo sembra rotto, aggiustalo" al commento di origine). Regolarmente prendi un giorno (cerco una volta al mese) di consultare l'elenco e registrarlo come appropriato: richiesta di funzionalità, segnalazione di bug, discussione con il manager, ecc ...

Nel corso del tempo, ho trovato utili tutti i tipi di modifiche. Ad esempio:

• In ambienti più rigidi, potrei semplicemente scaricare il lavoro di segnalazione dei bug al team di test: farmi incontrare un tester ogni ora per un ora, consegnargli l'elenco dei problemi e convincerli a fare il registrazione. In ambienti in cui i test di registrazione sono un grosso problema, di solito il tester sarà contento per la spinta gratuita alla loro produttività.
• Alcuni team si rifiutano di consentire eventuali correzioni che non riportano una segnalazione di bug del cliente. Conserverei un progetto pieno di correzioni sul lato e li commetto istantaneamente quando il problema pertinente viene segnalato da un cliente, per ottenere punti brownie gratuiti.
• Alcuni team richiedono che la persona che "possiede" una parte di codice sia quella che esegue le correzioni. Tratterei il "proprietario" del codice come un lead di test e ci incontriamo in modo informale per distribuire occasionalmente i problemi

Trovo che, generalmente, mentre segui questo tipo di strategia, sempre più colleghi e altri membri dell'azienda inizieranno a rispettare il tuo lavoro e l'impegno per la qualità. Dopo un tempo sufficiente, avrai il rispetto e l'autorità necessari per ottimizzare l'intero processo a tuo piacimento. Tieni d'occhio queste opportunità e prendile quando necessario.

Credo che se uno sviluppatore incontra un bug che non è relativo a quello che sta funzionando e che non risolverà il problema, dovrebbe inserirlo nel sistema solo per avere qualche record di esso . In questo modo, quando QA inizia a testare (e non sono ancora corretti) puoi dare loro questi bug di elenco come "difetti noti" in modo che non inizino a riportare gli stessi bug.

Forse altri sviluppatori che trovano bug ne tengono traccia da soli se hanno intenzione di risolverlo, ma in tal caso corrono il rischio che 2 sviluppatori scoprano e risolvano lo stesso errore.

Vorrei aggiungere che anche se il bug è già stato risolto (cosa che non dovrebbe essere accaduta prima di registrarlo in un tracker dei problemi) è una buona idea tenerne traccia.

In questo modo, se il problema si ripresenta in futuro (le regressioni accadono!) è relativamente facile riconoscere il problema come "già trattato" e leggere come è stato risolto la prima volta.

Perché è così? Poiché molti sviluppatori considerano il problema che devono affrontare e il codice che devono scrivere e capire è più facile non preoccuparsi.

Ma, se questa è la cosa giusta da fare dipende dal tuo processo. Hai una squadra di QA? Pensi che ti dispiaccia se vai a cambiare codice che non verrà tracciato? Che ne pensi delle recensioni di codice? Salterà da quella crepa? E il business? Hanno bisogno di sapere che hai corretto un bug in modo che non aumenti lo stesso dopo?

E gli altri sviluppatori? Cosa succede se lo risolvono in un modo diverso allo stesso tempo? Che cosa succede se trovano un bug simile più tardi e tutto quello che puoi fare è dire "oh, dannazione, so che abbiamo avuto qualcosa di simile prima - ora che cos'era?"

Ci sono circa un milione di motivi per registrare i bug nel sistema di tracciamento dei bug. Se sei SICURO di non aver colpito nessuno di questi problemi, allora non perdere tempo. Ma se non sei affatto sicuro, dovresti registrarlo, anche se la maggior parte delle persone non lo fa.

La programmazione è un lavoro complesso fondamentalmente. Gli errori sono complessi. quindi ho usato per valutare un bug in base a due fattori:

1. Quante volte un tale tipo di bug può comparire di nuovo in futuro? Se questa stima è accurata o meno, continua a stimare.
2. Quando compare nuovamente questo tipo di bug, è facile da capire? Questo è accurato quando analizzi questo bug e lo risolvi.

Classificerei un bug in uno dei seguenti tipi:

1. Riappare probabilmente in futuro e facile da capire
2. Probabilmente apparirà di nuovo in futuro, ma difficile da capire
3. Raramente appaiono di nuovo in futuro e facili da capire
4. Raramente appaiono di nuovo in futuro, ma difficili da capire

Nel caso 1, un libro di cucina o FAQ è un buon dispositivo per il team per correggere tali bug in futuro.

Nel caso 2, un record elaborato e comprensibile è necessario per la squadra perché è uno spreco di energie se un altro programmatore resiste nuovamente a tali bug. Ad esempio: perdita di memoria.

Nel caso 3, penso che non sia un grosso problema che non sia rimasto nulla per i record perché non si impiegherà troppo tempo per correggere un bug facile. Ad esempio, un errore di battitura per l'id dell'elemento in HTML.

Nel caso 4, tali bug creano un dilemma. Ha bisogno di tempo per scrivere un record elaborato e comprensibile per descrivere questi bug. Ma questo disco è usato raramente in futuro. Senza un record, tuttavia, l'apparizione di tali bug sarebbe di nuovo una lotta. Ad esempio, tali bug compaiono a causa di virus informatici nel computer di qualcuno.

Ovviamente dovresti inserirlo. O almeno segnalalo alle tue persone di controllo qualità se questo è il tuo normale processo.

Anche se si aggiustano il bug da soli, si vorrà una registrazione della modifica in modo che possa essere testata per assicurarsi che la correzione funzioni effettivamente e che non ci sia stata una regressione. È anche possibile che un utente possa segnalare il bug ad un certo punto, e se è nel sistema e contrassegnato come fisso, le persone di supporto possono dire che è già stato risolto.

In effetti dovresti registrarli nel sistema, e nel caso non sia praticato, allora è bene iniziare.

Nel mio passato facevo parte di un team di prodotto, eravamo nella versione beta di un nuovo prodotto e a volte trovavamo bug che a quel punto usavamo annotare e spedire alle rispettive persone che gestiscono i moduli (avevamo un sistema di tracciamento dei bug, ma non pensavamo di spingerli lì). Più tardi, quando i giorni trascorsero, gli articoli nella posta iniziarono a essere ignorati a causa di altre priorità e che alla fine portarono a notti insonni.

Quindi, bang un giorno, Nirvana! Perché non utilizziamo il bug tracker, anche se hai trovato qualcosa che sembra un bug e potrebbe essere possibile che non lo sia (il tuo pensiero sul processo è sbagliato / errato). Almeno fa parte dell'elenco che potrebbe quindi essere testato e il più importante di tutti un feedback sul motivo per cui è fondamentale o il rovescio della medaglia è perfetto ed è così che dovrebbe funzionare per motivi 1 ... 2 ....

Ora hai la lista e anche per coloro che hanno frainteso alcune parti dell'applicazione hanno il feedback basato su cui possono chiarire i loro pensieri. Una situazione vantaggiosa per tutti.

Assumendo assolutamente il codice già testato (e soprattutto se rilasciato)

Ci sono diversi motivi per questo:

Memoria : è improbabile che il sistema dimentichi il bug, qualsiasi sviluppatore potrebbe.

Metriche : il numero di bug trovati, chiusi e il tempo impiegato possono essere delle buone metriche facili da catturare per dirti come sta procedendo la qualità del tuo codice

Urgenza - Potrebbe sembrare la cosa più importante al mondo per lo sviluppatore, tuttavia il tempo speso per risolvere questo problema potrebbe essere speso meglio su qualcosa che gli utenti finali vogliono prima (vedi anche memoria ).

Duplicazione - Forse è già stato individuato ed è in fase di esame / correzione da parte di qualcun altro. In alternativa, forse è caduto in fallo della regola di urgenza ed è stato rimandato. Naturalmente il fatto che tu l'abbia trovata di nuovo non significa solo che non dovrebbe essere fatto, potrebbe significare che (come continua a venire) che è ora è più urgente risolvere.

Analisi delle cause principali - Il bug più semplice da correggere è quello che non c'è mai stato. Potrebbe essere che il team dovrebbe guardare questo bug per scoprire come è arrivato. Questo è importante non punire il responsabile (che non aiuta mai) ma scoprire come la situazione può essere evitata in futuro.

Analisi dell'impatto più ampia : il bug più economico per trovare è quello che conoscevi prima di trovarlo. Osservando questo bug (in particolare dopo aver fatto l'analisi delle cause alla radice) può essere presto chiaro che questo problema potrebbe esistere in altri punti del codice. Di conseguenza, la squadra può scegliere di trovarla prima che sollevi la sua brutta testa in un momento più imbarazzante.

La quantità di tempo speso per questi (se ce ne sono) dipende in larga misura dalla maturità e dal livello di qualità del codice. È probabile che l'analisi delle cause principali sia eccessiva per un piccolo team che lavora sul codice dimostrativo, ma un team di grandi dimensioni in fase di sviluppo business-critical probabilmente ha bisogno di imparare le lezioni in modo efficace ed efficiente.

Dall'esperienza ci sono due grandi ragioni per cui gli sviluppatori evitano di utilizzare lo strumento:

1. Lo strumento di gestione degli errori e / o il processo sono considerati troppo pesanti per lo sviluppo
2. Gli sviluppatori trovano la sfida mentale di correggere il bug più interessante di quello su cui stanno lavorando attualmente.

L'articolo 1 implica che potrebbe essere necessario un sistema migliore / più semplice; o in alternativa una giustificazione più convincente del sistema esistente potrebbe essere in ordine.

L'elemento 2 dovrebbe essere un utile segnale di avvertimento per il lead di sviluppo sulle attuali assegnazioni dei compiti.

Sono per lo più d'accordo con FrustratedWithFormsDesign ma penso che sia ancora più chiaro se l'intero problema è suddiviso in due aree:

• Segnalazione di bug.
• Correzione di bug.

Questi sono spesso considerati uguali e separarli li aiuterà quasi sicuramente molto.

Questi possono essere gestiti con: Segnalazione errori: - Inseriscilo nel sistema, come dicono tutti.

Correzione dei bug: - Ogni settimana o due (aggiustare il tuo programma di sviluppo, ecc.) tutti si riuniscono sul progetto e decidono cosa dovrebbe essere corretto, da chi, ecc. Questi erano tutti sulla stessa pagina e possono vedere cosa deve essere fatto In Agile Development questa è la riunione di Sprint Planning.

Un ottimo strumento che le persone vogliono utilizzare fa anche una grande differenza. Mi piace Pivotal Tracker e ha superato il mio test "strumento davvero utile" quando ho iniziato a utilizzarlo solo per tenere traccia delle cose che voglio fare o correggere nei miei progetti privati!

Se vedi qualcosa, allora di 'qualcosa!

Inserisco perfino segnalazioni di bug sui miei moduli perché non voglio interrompere il mio compito corrente. E posso assicurarmi che tutti i passaggi da riprodurre siano inclusi: -)

Ed è ancora meglio quando qualcun altro può vedere che hai elencato qualcosa come un bug noto. A loro piace sapere che anche qualcun altro l'ha trovato.

Penso che questa sia più una domanda politica di una domanda sulla best practice.

• la voce del bug è incolpata di sombody?
• il cliente può leggere le voci dei bug e vede che ci sono errori aggiuntivi. Si tratta di un problema di reputazione per la tua azienda?
• è davvero un bug o una funzionalità di cui non sei a conoscenza?
• chi pagherà la correzione?

Secondo me è una buona pratica aggiungere bug non banali al sistema tracker ma la direzione deve decidere come affrontarlo.

Per i casi non banali non si dovrebbe risolvere il problema senza consultare qualcun altro per creare shure che

• questo è davvero un bug e non una funzionalità
• sombody else può testare la correzione e fare in modo che la correzione non introduca un nuovo bug elsewere (regressione)