Che cos'è il bug tracking? La differenza tra una traccia e un messaggio

Il bug tracking consiste nel tenere ogni difetto noto in un solo posto, in una forma che sopravvive alla persona che l’ha trovato quando va in ferie. È tutta qui l’idea. Il software a cui si pensa dicendo “bug tracker” non è che lo schedario che rende la cosa possibile.

La distinzione che conta è quella tra una traccia e un messaggio. Un messaggio è quello che mandi quando noti qualcosa: una riga in chat, una mail, una parola detta passando vicino alla scrivania di qualcuno. È rivolto a una persona, si legge una volta, e poi non c’è più. Una traccia non è rivolta a nessuno in particolare e si legge ogni volta che qualcuno fa la domanda giusta. Il bug tracking è la pratica di trasformare il primo nella seconda.

Che cosa deve fare un tracker

Quattro cose. Tutto il resto è comodità.

• Tenere una voce per problema, così due persone che trovano la stessa cosa si trovano tra loro invece di segnalare due volte.
• Dire a che punto è ognuna - aperta, in lavorazione, corretta, verificata, chiusa - in un modo che sia vero e non augurale.
• Indicare un responsabile, perché un difetto che appartiene al team non appartiene a nessuno.
• Restare cercabile in seguito, che è la cosa che si salta quando si sceglie e si rimpiange al quarto mese.

Un foglio di calcolo fa male le prime tre e la quarta per niente. Un canale di chat non ne fa nessuna, il che non è una critica alla chat: è un mezzo per messaggi che fa esattamente quello per cui esiste.

Che cosa va in una voce

Meno di quanto chiedano quasi tutti i modelli e più di quanto portino quasi tutte le segnalazioni.

Le parti che si guadagnano il posto sono quelle che servono a un altro per agire: che cosa è successo, che cosa ci si aspettava invece, come tornarci, e dove è successo - browser, build, account, URL. La nostra guida a scrivere una segnalazione di bug è la versione lunga di questo elenco, e porta con sé un modello da incollare in un modulo.

Tutto il resto di un modulo tipico sono metadati del processo e non del problema: gravità, priorità, componente, milestone, la persona che se ne occupa. Utili, ma appartengono a chi guida la gestione dei difetti, non a chi si è accorto che il pulsante era rotto. Chiederli a chi segnala, nel momento in cui segnala, è il modo più comune di rendere la segnalazione così costosa che la gente smette.

Tre modi di fallire

Quasi ogni tracker che smette di essere creduto ci è arrivato per una di tre strade.

Il cimitero. Non si chiude mai niente, quindi il conteggio cresce e basta, quindi nessuno legge l’elenco, quindi arrivano difetti veri e non li vede nessuno. Un arretrato di ottocento voci che quest’anno nessuno ha aperto non è la traccia di niente; è un posto dove le cose vanno a finire.

Stati che mentono. Ogni voce dice “aperta” perché spostarle è il lavoro di qualcuno e nessuno ce l’ha. A quel punto il campo di stato è decorazione e l’unico modo di sapere a che punto è qualcosa è chiederlo a una persona, cioè proprio quello che il tracker doveva sostituire.

La pila di duplicati. Lo stesso difetto segnalato sei volte perché cercare costa più che scrivere. Di solito se ne dà la colpa a chi segnala ed è di solito un problema di ricerca: se cercare le parole che userebbe una persona normale non trova la voce che c’è già, il tracker le ha insegnato a segnalare di nuovo.

Da dove arrivano le voci conta più di quale strumento le tiene

I team passano molto tempo a scegliere tra tracker e quasi nessuno sul passo precedente, che è come un difetto arrivi dalla persona che l’ha visto dentro al tracker.

È su quel percorso che le segnalazioni muoiono. Qualcuno nota un problema, e tra il notarlo e l’aver scritto una voce utile c’è un vuoto: che browser era, che cosa diceva la console, qual era l’URL, su che cosa ho cliccato per primo. Quasi tutti, quasi sempre, scriveranno due frasi e andranno avanti, perché l’alternativa sono quindici minuti di indagine per un bug che non è il loro.

Tutto ciò che accorcia quel vuoto alza la qualità di quanto viene dopo. Un modulo sulla pagina dove il bug è successo batte un link al tracker. Una cattura che raccoglie da sola la metà tecnica batte il chiedere a un addetto al supporto di aprire gli strumenti per sviluppatori. Catturare la segnalazione dov’è il bug è lo stesso problema visto dall’altro capo.

Sceglierne uno

Il consiglio onesto è che la scelta conta meno dell’abitudine. Jira, Linear, GitHub Issues, Bugzilla, Trello con una colonna chiamata Bug: tutte e quattro le cose di sopra si possono ottenere in ognuno di essi, e nessuno le farà al posto vostro.

Vale la pena porre due domande a un candidato, e non sono quelle delle pagine di confronto:

Domanda debole

Quale ha più integrazioni e le dashboard di reportistica migliori?

Domanda migliore

Chi non è nel team di sviluppo riesce a segnalare senza aiuto, e si riesce a ritrovare una voce di due anni fa a partire dalle parole che si ricordano?

Se segnalare richiede un account, un progetto, un componente e un tipo di ticket, le persone più vicine ai vostri clienti - supporto, vendite, QA, il cliente stesso - non segnaleranno. I loro bug arriveranno come messaggi, e la differenza tra una traccia e un messaggio era proprio quello che stavate cercando di comprare.

Tracking, test e tutto il resto

Il bug tracking sta a valle di tutto ciò che trova bug, ed è per questo che raccoglie il lessico di tutto quanto. Un piano di test dice come si segnalano i difetti e chi decide se uno ferma un rilascio. I test di regressione esistono perché un tracker pieno di voci chiuse è un elenco di cose che una volta funzionavano. I test instabili sono ciò che succede quando la cosa tracciata non riesce a decidere se è un difetto.

Un tracker non migliora il software. Impedisce che lo stesso pomeriggio venga speso due volte.