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

Durante lo sviluppo (funzionalità o correzione di errori) a volte mi capita di scoprire bug che non sono direttamente correlati a ciò su cui sto lavorando. Cosa dovrei fare in quella situazione. Basta aggiustarlo? Prova a ricordare di ripararlo più tardi? Scrivilo da qualche parte? Oppure inseriscilo nel sistema di tracciamento dei bug?

In genere lo inserisco nel sistema di tracciamento dei bug e lascio che il processo si svolga da solo (ovvero triaging, assegnazione, ecc.). Tuttavia non ho quasi mai visto un altro sviluppatore inserire un bug. (Perché?)

Se scopri un bug, non riesco a pensare a nessuna buona ragione per non inserirlo nel sistema di tracciamento dei bug, che lo correggi o no. Ecco a cosa serve il sistema di tracciamento dei bug, dopo tutto.

In alcuni casi potrebbe essere più sensato segnalarlo a un addetto al controllo qualità che ha più esperienza con il sistema, ma in ogni caso il bug dovrebbe essere rintracciato.

È possibile che ci sia qualche motivo, valido o no, che gli sviluppatori non debbano inserire bug. Una possibile ragione potrebbe essere che il sistema di tracciamento dei bug sia visibile agli estranei e che avere troppi bug segnalati non sia corretto. Questa è una pessima ragione, che dovrebbe essere affrontata in qualche altro modo che permetta ancora di rintracciare i bug. Chiedi al tuo capo.

(Ovviamente se c'è un bug nel codice su cui stai ancora lavorando, e non viene visualizzato in tutto ciò che è stato rilasciato, non è necessario tracciarlo nel sistema, anche se un commento TODO nel codice sorgente 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 da segnalare.)

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

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

• quando il bug riguarda direttamente il codice su cui stai lavorando,

• quando il bug riguarda il codice su cui non stai lavorando in questo momento o la parte su cui lavora un altro sviluppatore.

Questo è essenziale, dal momento che il sistema di tracciamento dei bug è fatto per ... tenere traccia dei bug. Ogni insetto. 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, sarai in grado di collegarlo al tuo rapporto. Se non hai nulla a cui collegarti, perderai il tuo tempo (o il tuo collega) nella ricerca del bug nelle revisioni precedenti, quindi proverai a risolverlo e alla fine scoprirai che il bug era già stato risolto magicamente.

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

Non esiste un motivo valido per non inserire un difetto nel sistema di rilevamento dei difetti. L'unico posto in cui ho visto correzioni di bug applicate senza tracciamento è perché il processo è stato sostanzialmente interrotto. In tal caso, correggere il processo.

i motivi per non entrare sono:

• Il processo misura e punisce in base alla segnalazione dei difetti: non denunciare, non essere punito. In questo caso lascia l'organizzazione
• Il processo è un onere: sono necessari troppi sforzi e tempo per inserire un difetto e arrivare al punto di risolverlo. Il processo dovrebbe essere modificato per consentire agli sviluppatori di rintracciare rapidamente un bug leggero attraverso il processo triage / accept / fixed.
• Alcuni sviluppatori sono pigri / sciatti / hacker a cui non importa quale potrebbe essere l'impatto delle cose che fanno sugli altri. Recluta sviluppatori professionisti.
• Sono una band composta da un solo uomo, non capisco il punto. Vai a lavorare per una band di 2 uomini e tu ....

Correggere subito il bug è probabilmente una cattiva idea. Innanzitutto, qualcun altro potrebbe lavorare sulla stessa correzione, con conseguente sforzo duplicato, e inoltre, a seconda della metodologia di sviluppo che stai seguendo, dare la priorità su cosa lavorare in seguito (correggere un bug o implementare una nuova funzionalità) è più di un decisione di gestione quindi una decisione di sviluppo.

La decisione non è ben definita e comporta compromessi.

(alcuni) PRO

Il tracciamento dei bug è essenziale per la comunicazione, specialmente su team di grandi dimensioni. Uno dei migliori vantaggi di avere più occhi sul codice è la capacità di rilevare i problemi in precedenza e tale vantaggio viene perso se i bug non vengono registrati o tracciati durante lo sviluppo.

• Spesso, i bug vengono risolti più facilmente mentre si è già in una parte del codice, lavorando per capirlo.
• Anche nelle squadre più piccole, ci sono molti vantaggi da ottenere dal punto di vista morale, essendo in grado di elencare i bug e fare progressi nel risolverli - a volte il vantaggio morale è cruciale anche per i progetti di un uomo.
• Il rilevamento accurato di un bug può essere molto difficile dopo il fatto: vedere un bug nel codice può salvare un sacco di lavoro successivo giocando a detective, cercando di capire dove si è verificato il problema in origine.
• È positivo per il tuo sviluppo generale come sviluppatore prestare attenzione ai bug quando li vedi e prendere l'abitudine di migliorare / ripulire / leggere il codice in modo critico

La registrazione dei bug come li trovi è, in generale, una buona abitudine.

(alcuni) CONS

Inserire i bug in un sistema di tracciamento dei bug può essere oneroso e richiedere molto tempo, e può davvero disturbare il lavoro di sviluppo, più spesso quando si lavora in team di grandi dimensioni. Ci si può aspettare di:

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

A volte il tracciamento dei bug non è solo 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 ottimizzo come richiesto per un determinato progetto, team, ambiente di lavoro e le tue abilità generali. La mia strategia di solito segue uno schema approssimativamente come segue:

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

• Prenditi del tempo all'inizio di ogni nuova giornata lavorativa, come parte del tuo riscaldamento per il lavoro, per affrontare gli sticky. Impiego 10-15 minuti per consultare l'elenco dei problemi rilevati dal giorno prima e fare qualunque delle seguenti operazioni sia la più veloce:

  • Risolvi il problema e risolvilo (probabilmente per correzioni o errori di battitura di una riga). Se non ti è consentito eseguire il commit senza una segnalazione di bug, crea un progetto laterale per piccoli commit. Quando nel progetto secondario si accumulano abbastanza correzioni, prenditi le poche ore necessarie per documentarle e impegnarle.
  • Registra il problema in un sistema di tracciamento dei bug (per ovvi problemi che richiedono più tempo per essere risolti, ma senza spese generali onerose)
  • Registra il problema in un documento "da guardare quando non occupato" (di solito aggiungo un commento "// TODO - questo sembra rotto, risolvilo" alla fonte). Prenditi regolarmente un giorno (provo per una volta al mese) per 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. Per esempio:

• In ambienti più rigidi, potrei semplicemente scaricare il lavoro di segnalazione dei bug al team di test: chiedere a un tester di incontrarmi con me ogni ora ogni tanto, consegnare loro l'elenco dei problemi e convincerli a fare la registrazione. In ambienti in cui i test di registrazione sono un grosso problema, di solito il tester sarà contento per l'aumento gratuito della sua produttività.
• Alcuni team si rifiutano di consentire eventuali correzioni che non hanno una segnalazione di bug del cliente dietro di loro. Terrei un progetto pieno di correzioni sul lato e le commetterei immediatamente quando un cliente segnala un problema rilevante, per ottenere punti brownie gratuiti.
• Alcuni team richiedono che la persona "proprietaria" di un pezzo di codice sia quella che esegue le correzioni. Tratterei il codice "proprietario" come un responsabile del test e mi incontrerei in modo informale per consegnare i problemi occasionalmente

Trovo che, generalmente, seguendo questo tipo di strategia, sempre più colleghi e altri membri dell'azienda inizieranno a rispettare il proprio 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 come appropriato.

Credo che se uno sviluppatore incontra un bug che non è correlato a ciò che sta funzionando e che non risolverà, dovrebbe inserirlo nel sistema solo per averne una traccia. In questo modo, quando il QA inizia a testare (e non sono ancora corretti) puoi dare loro questo elenco di bug come "difetti noti" in modo che non inizino a segnalare gli stessi bug.

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

Aggiungo che anche se il bug è già stato corretto (cosa che non avrebbe dovuto succedere prima di registrarlo in un tracker di problemi) è una buona idea rintracciarlo.

In questo modo, se il problema dovesse ripresentarsi in futuro (si verificano regressioni!) È relativamente facile riconoscere il problema come "già risolto" e leggere come è stato risolto la prima volta.

Perché? Poiché la maggior parte degli sviluppatori osserva il problema che devono sollevare e il codice che devono scrivere e capire è più facile non disturbare.

Ma se questa è la cosa giusta da fare dipende dal tuo processo. Hai una squadra di controllo qualità? Pensi che gli dispiaccia se vai semplicemente a cambiare codice che non verrà monitorato? Che dire delle recensioni di codice? Salterà da quella crepa? E il business? Devono sapere che hai corretto un bug in modo che non sollevino lo stesso in seguito?

E gli altri sviluppatori? E se lo riparassero in un modo diverso allo stesso tempo? E se trovassero un bug simile in un secondo momento e tutto ciò che puoi fare è dire "oh, accidenti, so che abbiamo avuto qualcosa di simile prima - ora che cosa era?"

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

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

1. Con quale frequenza questo tipo di bug potrebbe ripresentarsi in futuro? Se questa stima è accurata o no, continua a stimare.
2. Quando questo tipo di bug appare di nuovo, è facile da capire? Ciò è accurato quando si analizza questo errore e lo si risolve.

Classificherei un bug in uno dei seguenti tipi:

1. Probabilmente riapparirà in futuro e facile da capire
2. Probabilmente riapparirà in futuro, ma difficile da capire
3. Raramente riappariranno in futuro e di facile comprensione
4. Raramente riappariranno in futuro, ma difficile da capire

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

Nel caso 2, un record elaborato e comprensibile è necessario per il team perché è uno spreco di sforzo se un altro programmatore persegue nuovamente tali bug. Ad esempio: perdita di memoria.

Nel caso 3, penso che non sia un grande problema che non sia rimasto nulla da registrare perché non passerai troppo tempo a correggere un bug facile. Ad esempio, un refuso per l'id dell'elemento in HTML.

Nel caso 4, tali bug creano un dilemma. È necessario del tempo per scrivere un documento elaborato e comprensibile per descrivere tali bug. Ma questo disco verrà usato raramente in futuro. Senza una registrazione, tuttavia, la comparsa di tali bug sarebbe di nuovo una lotta. Ad esempio, tali bug compaiono a causa del virus nel computer di qualcuno.

Ovviamente dovresti inserirlo. O almeno segnalalo ai tuoi addetti al QA se questo è il tuo normale processo.

Anche se risolvi il bug da solo, ti consigliamo di registrare la modifica in modo che possa essere testata per garantire che la correzione funzioni effettivamente e che non vi sia stata una regressione. È anche possibile che un utente possa segnalare il bug a un certo punto, e se si trova nel sistema e contrassegnato come riparato, il personale di supporto può dire loro che è già stato risolto.

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

Nel mio passato facevo parte di un team di prodotti, 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 gestivano i moduli (avevamo un sistema di tracciamento dei bug, ma non abbiamo pensato di spingerli lì). Più tardi, quando passavano i giorni, gli articoli della posta iniziarono a essere ignorati a causa di altre priorità e che alla fine portavano ad alcune notti insonni.

Quindi, bang un giorno, Nirvana! Perché non stiamo usando 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 / imperfetto). Almeno fa parte dell'elenco che potrebbe quindi essere testato e, soprattutto, un feedback sul perché è critico o sul rovescio della medaglia è perfetto ed è così che dovrebbe funzionare a causa dei motivi 1 ... 2 ... .

Ora hai l'elenco e anche per coloro che hanno frainteso alcune parti dell'applicazione hanno il feedback in base al quale possono chiarire i loro pensieri. Una situazione vantaggiosa per tutti.

Supponendo che il suo codice già testato (e in particolare se rilasciato) sia assolutamente.

Ci sono diverse ragioni per questo:

Memoria : è molto improbabile che il sistema dimentichi il bug, qualsiasi sviluppatore può.

Metriche : il numero di bug trovati, chiusi e il tempo impiegato può essere una buona metrica facile 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 impiegato per risolvere questo problema potrebbe essere meglio speso per qualcosa che gli utenti finali desiderano per primi (vedi anche memoria).

Duplicazione - Forse è già stata individuata ed è sotto esame / correzione da qualcun altro. In alternativa, forse è caduto in fallo per la regola dell'urgenza ed è stato rimandato. Naturalmente il fatto di averlo trovato di nuovo non significa solo che non dovrebbe essere fatto, potrebbe significare che (poiché continua a emergere) che è ora è più urgente da risolvere.

Analisi della causa principale : il bug più semplice da correggere è quello che non c'era mai stato. È possibile che il team stia guardando questo bug per scoprire come è arrivato. Questo è sicuramente non per punire il responsabile (che non aiuta mai) ma per scoprire come la situazione può essere evitata in futuro.

Analisi dell'impatto più ampia : il bug più economico da trovare è quello che conoscevi prima di trovarlo. Osservando questo bug (in particolare dopo aver fatto l'analisi della causa principale), potrebbe presto diventare chiaro che questo problema potrebbe esistere in altre parti del codice. Di conseguenza, il team può scegliere di cercarlo prima che alzi la brutta testa in un momento più imbarazzante.

La quantità di tempo che viene speso per questi (se presente) dipende in gran parte dalla maturità e dal livello di qualità del codice. È probabile che l'analisi della causa alla radice sia eccessiva per un piccolo team che lavora sul codice dimostrativo, ma un grande team sullo sviluppo critico aziendale probabilmente deve imparare le lezioni in modo efficace ed efficiente.

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

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

Il punto 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.

Il punto 2 dovrebbe essere un utile segnale di avvertimento al responsabile dello sviluppo sulle allocazioni di attività correnti.

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

• Segnalazione di bug.
• Bug Fixing.

Questi sono spesso trattati come gli stessi e separarli aiuterà quasi sicuramente molto.

Questi possono essere gestiti con: Segnalazione bug: - inseriscilo nel sistema, come dicono tutti.

Correzione di bug: - Ogni settimana o due (adeguati al tuo programma di sviluppo, ecc.) Tutti si riuniscono sul progetto e decidono cosa dovrebbe essere risolto, da chi, ecc. Questo era che tutti sono sulla stessa pagina e possono vedere ciò che deve essere fatto. In Agile Development questo è il meeting Sprint Planning.

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

Se vedi qualcosa, allora dì qualcosa!

Inserisco anche segnalazioni di bug sui miei moduli perché non desidero interrompere la mia attività corrente. E posso garantire che tutti i passaggi per la riproduzione 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 che una domanda sulla migliore pratica.

• la voce dell'insetto dà la colpa a sombody?
• il cliente può leggere le voci di bug e vede che ci sono errori adizionali. È 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 nel sistema tracker ma il management deve decidere come affrontarlo.

Per casi non banali non dovresti risolvere il problema senza consultare qualcun altro per assicurarti che

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