10 errori comuni nelle segnalazioni di bug (e come evitarli)

Una segnalazione di bug ha un solo compito: mettere chi non ha mai visto il problema in condizione di riprodurlo al primo tentativo. La maggior parte fallisce proprio lì, e di rado per mancanza di impegno. Falliscono per una manciata di abitudini, ripetute da persone scrupolose che non hanno mai visto la propria segnalazione atterrare sulla scrivania di qualcun altro.

Ogni dettaglio omesso costa secondi da scrivere e ore da recuperare: un giro nel filo dei commenti, uno sviluppatore che ricostruisce uno stato in cui lei era già seduta, un ticket chiuso come non riproducibile e riaperto due settimane dopo da qualcun altro. Lei è l’unica persona che avrà mai quel contesto gratis.

Dieci abitudini, in due gruppi. Le prime sei sono giudizio, e nessuno strumento le farà mai al posto suo. Le ultime quattro sono contesto che esisteva nel momento del bug e che nessuno ha annotato.

1. Un titolo che descrive una sensazione
2. Nessun passo per riprodurre
3. Nessun comportamento atteso
4. Più bug in un solo ticket
5. Emozione al posto dell’impatto
6. Non cercare i duplicati
7. Tralasciare l’ambiente
8. Descrivere quello che ha visto invece di mostrarlo
9. Saltare la console e la scheda di rete
10. “Sul mio computer funziona”, senza nulla in allegato

Se cerca il metodo anziché le trappole, l’articolo compagno su come scrivere una segnalazione di bug perfetta ne contiene l’anatomia.

Quello che può scrivere solo lei

1. Un titolo che descrive una sensazione

“Il checkout è rotto.” “Il login non funziona.” “C’è qualcosa che non va con le immagini.”

Un titolo viene letto molte volte e aperto una sola. Compare nei risultati di ricerca, nelle riunioni quotidiane, nelle note di rilascio e nella lista che qualcuno scorre decidendo cosa prendere stamattina. Un titolo che potrebbe descrivere quaranta difetti diversi rende più lento ognuno di quei momenti.

Lo schema è cosa si è rotto, più dove o quando, più l’unico dettaglio che separa il suo caso da quello di tutti gli altri a cui funziona.

Debole

Immagini rotte

Migliore

Le immagini prodotto non si caricano su Chrome mobile quando la pagina viene aperta dalla ricerca

Punti a una frase che qualcuno possa ripetere ad alta voce senza aprire il ticket.

2. Nessun passo per riprodurre

Senza passi uno sviluppatore non sta facendo debug, sta indovinando cosa ha fatto lei. Ogni tentativo sbagliato finisce in cannot reproduce, il ticket torna indietro e il cronometro riparte.

I passi devono partire da uno stato che chiunque possa raggiungere.

Debole

Vai nel mio carrello e prova a pagare

Migliore

1. Accedi come cliente con il carrello vuoto. 2. Aggiungi due articoli qualsiasi. 3. Applica il codice SAVE10. 4. Clicca su Prosegui al pagamento.

Quattro righe, e chi legge si trova dove si trovava lei. Consegni i suoi passi a un collega che non ha visto il bug. Se torna con una domanda, la domanda è il suo passo mancante.

3. Nessun comportamento atteso

“Il totale è sbagliato” dà per scontato che chi legge sappia com’è quello giusto. Spesso non lo sa, e a volte quello che sta segnalando si rivela una regola che non conosceva.

Scriva entrambe le metà.

Debole

Lo sconto è sbagliato

Migliore

Atteso: il totale mostra 45,00 dopo lo sconto del 10 %. Effettivo: il totale mostra 50,00 e la riga dello sconto non c'è.

È anche così che si scopre che lei e lo sviluppatore non siete d’accordo su a cosa serva la funzionalità, una conversazione che conviene avere nel ticket anziché tre settimane dopo.

4. Più bug in un solo ticket

Aprire tre problemi insieme sembra efficiente. Non lo è, perché un ticket ha un solo stato. Quando due dei tre sono risolti, il ticket non è né fatto né da fare, e il terzo problema sparisce in silenzio sotto una discussione che si legge come conclusa.

Un difetto per ticket. Se hanno una causa comune, lo dica e li colleghi.

5. Emozione al posto dell’impatto

“È inutilizzabile.” “Com’è possibile che sia uscito così?” “Terza volta questa settimana.”

La frustrazione è legittima. Un bug le ha appena mangiato il pomeriggio. Ma soffoca l’informazione che farebbe sistemare la cosa, e mette chi legge sulla difensiva proprio quando le serve la sua attenzione sul problema.

L’impatto ha il suo posto in una segnalazione. Lo dichiari come un fatto, e dia a chi smista abbastanza per fissare una priorità senza indovinare: quante persone sono colpite, con quale frequenza, se sono in gioco soldi o dati, se esiste un modo per aggirarlo e se prima funzionava.

Debole

È un disastro, sistematelo subito

Migliore

Blocca il pagamento per tutti i clienti Safari, nessun aggiramento, iniziato dopo il rilascio di martedì

Il secondo è molto più allarmante del primo, e molto più probabile che venga preso oggi. Un bug che impedisce a una persona di cambiare avatar e un bug che impedisce a ogni cliente di pagare non dovrebbero mai arrivare con lo stesso aspetto.

6. Non cercare i duplicati

I duplicati costano due volte: una quando qualcuno smista una segnalazione già nota, e un’altra quando la discussione di un problema è divisa su due ticket e nessuno dei due contiene la storia intera.

Cerchi nel tracker il messaggio di errore, il nome della pagina e una o due parole del titolo che stava per scrivere. Cerchi anche fra i ticket chiusi, perché un bug che era stato risolto e che torna è una regressione, e dirlo cambia il modo in cui viene gestito.

Cercare è anche il modo più rapido per imparare le parole che il suo team usa davvero. Se tutti gli altri lo chiamano cestino e lei lo chiama carrello, la prossima persona che cercherà non troverà la sua segnalazione, e lei non troverà la loro.

Quello che il browser sa già

I quattro che seguono sono di natura diversa. Nessuno tralascia la versione del browser per risparmiarsi fatica. La tralascia perché registrarla significa lasciare la pagina, andare a caccia di una stringa di versione e digitarla in un modulo, e per allora la scheda è chiusa.

7. Tralasciare l’ambiente

Un bug che capita ovunque e un bug che capita in un solo browser sono bug diversi con cause diverse, e nessuno può dire quale dei due ha lei finché qualcuno non controlla. È così che una segnalazione viene chiusa come non riproducibile: lo sviluppatore ha provato in Chrome, e lei era in Safari.

Registri il browser e la sua versione, il sistema operativo, il dispositivo e la dimensione della finestra se il layout è anche solo in parte coinvolto. Latest Chrome non è una versione. Il giorno in cui viene letto significa qualcosa di diverso dal giorno in cui è stato scritto.

8. Descrivere quello che ha visto invece di mostrarlo

La prosa è un formato con perdita per un problema visivo. “Il layout impazzisce più in basso” può voler dire una mezza dozzina di cose, e quella mezza dozzina ha correzioni diverse.

Uno screenshot risolve di colpo i problemi di layout e di testo. Una registrazione breve è meglio per tutto ciò che riguarda tempi, animazioni o una sequenza di interazioni. Catturi l’intera finestra anziché un ritaglio della parte rotta: la barra degli indirizzi, la console e la pagina intorno contengono spesso la risposta.

9. Saltare la console e la scheda di rete

È la prima cosa che uno sviluppatore chiede e l’ultima che la maggior parte delle segnalazioni contiene. Un errore rosso in console di solito nomina il file e la riga che non funzionano. Una richiesta fallita nella scheda di rete di solito nomina il codice di stato e l’endpoint. Ognuna delle due può trasformare un pomeriggio di bisezione in una correzione di due minuti.

Apra gli strumenti per sviluppatori prima di chiudere la scheda. Copi il testo dell’errore invece di fotografarlo, così resta cercabile. Se una richiesta è fallita, annoti il suo stato e il suo percorso.

10. “Sul mio computer funziona”, senza nulla in allegato

La frase chiude una conversazione senza risolvere niente, e funziona in entrambe le direzioni. Da uno sviluppatore significa che alla segnalazione mancava il dettaglio per riprodurre. Da chi segnala, rispondere a una correzione con “da me è ancora rotto” e nient’altro significa esattamente la stessa cosa al contrario.

In un caso e nell’altro la risposta è la prova anziché l’affermazione: la versione che ha provato, l’ambiente in cui l’ha provata e quello che ha visto. Una segnalazione su una correzione fallita merita la stessa cura di quella originale.

Quello che risolve davvero metà di tutto questo

Torni al secondo gruppo. Gli errori 7, 8, 9 e 10 sono un solo problema con quattro cappelli: il contesto esisteva nel momento del bug, e nessuno l’ha annotato.

È la parte che vale la pena automatizzare, ed è per questo che abbiamo costruito Session Replay.

Non sa su cosa ha cliccato. Sa quello che sapeva il browser. Quindi non le scriverà il titolo, non dividerà i suoi tre bug in tre ticket e non le dirà cosa si aspettava. Quello è giudizio, e resta suo. Quello che toglie è la scusa per le quattro abitudini che erano sempre e solo attrito, e le lascia le sei che riguardano il pensare con chiarezza.

La lista di controllo

Prima di premere invia:

• Il titolo dice cosa è fallito, dove e a quale condizione
• I passi partono da uno stato che chiunque può raggiungere
• Comportamento atteso ed effettivo sono scritti entrambi
• Un difetto in questo ticket, e uno solo
• Impatto dichiarato come un fatto, con abbastanza perché un altro fissi la priorità
• Ho cercato una segnalazione esistente fra i ticket aperti e chiusi
• Browser, versione, sistema operativo e dispositivo sono registrati
• È allegato uno screenshot o una registrazione che mostra l’intera finestra
• Gli errori di console e le richieste fallite sono riportati come testo
• Una prova per tutto quello che affermo, compreso “succede ancora”