Dal lamento al bug report

In parole semplici

La maggior parte delle segnalazioni di bug suona così: “Non funziona”. È un lamento, non un bug report. Per indagare ti serve una scheda con campi precisi che chiunque possa leggere, ripetere e verificare. Questa lezione introduce un template canonico e ti allena a riempirlo.

Parole nuove

• bug report: scheda strutturata che descrive un bug.
• passi (steps to reproduce): sequenza esatta di azioni per riprodurre il bug.
• atteso vs osservato: cosa dovrebbe succedere, cosa succede davvero.
• evidenza: prove materiali (screenshot, log, registrazione).
• severità: impatto del bug. Priorità: urgenza di risolverlo. Non sono la stessa cosa.

Cosa impari

• Riconoscere quando una segnalazione è inutilizzabile.
• Scrivere un bug report usando un template canonico.
• Capire la differenza tra severità e priorità.

Il template canonico

TITOLO: <una frase, sintomo + contesto>

AMBIENTE:
- sistema operativo:
- browser/versione:
- versione applicazione/commit:
- account o ruolo:
- dati di partenza (fixture):

PASSI:
1.
2.
3.

ATTESO:
<cosa dovrebbe succedere>

OSSERVATO:
<cosa succede davvero>

FREQUENZA:
[ ] sempre   [ ] a volte   [ ] una volta sola
condizioni che lo scatenano:

EVIDENZE:
- screenshot:
- log:
- registrazione:
- link riproduzione:

SEVERITÀ: [ ] critica [ ] alta [ ] media [ ] bassa
PRIORITÀ: [ ] subito [ ] sprint [ ] backlog

Severità vs priorità

Confusione classica.

• Severità = impatto tecnico/utente. “Crash dell’app” = critica. “Tooltip sfasato” = bassa.
• Priorità = urgenza di lavoro. Dipende da quante persone colpisce, da scadenze, da contratti.

Un bug può avere severità alta ma priorità bassa (es. funzione rotta usata da due utenti l’anno). E viceversa: severità bassa ma priorità alta (es. errore di copyright in homepage prima di un keynote).

Tre segnalazioni “vaghe” da riscrivere

Vaga 1

“Il bottone Salva non va.”

Da questa frase non sappiamo: quale bottone, in quale pagina, con quale utente, con quale dato, e cosa significa “non va”.

Versione utile:

TITOLO: Salva ordine non persiste lo stato dopo refresh in carrello multi-prodotto

AMBIENTE:
- macOS 14.4, Safari 17.4
- app v2.3.1 (commit a1b2c3)
- utente standard
- carrello con 3 prodotti, totale 49,90 €

PASSI:
1. Login come standard@test.it
2. Aggiungere 3 prodotti al carrello
3. Cliccare "Salva ordine"
4. Attendere il messaggio "Salvato"
5. Ricaricare la pagina (Cmd+R)

ATTESO: il carrello mostra ancora 3 prodotti.
OSSERVATO: il carrello è vuoto.

FREQUENZA: sempre, con qualunque utente e prodotto.
EVIDENZE: screenshot pre/post refresh, log Network in allegato.
SEVERITÀ: alta. PRIORITÀ: sprint.

Vaga 2

“A volte i numeri sono sbagliati.”

Manca tutto: quali numeri, quali condizioni, di quanto si discostano.

Vaga 3

“Non riesco più ad accedere.”

Manca: con che account, da quale browser, con quale messaggio di errore.

Esercizio guidato

1. Cerca tre segnalazioni vaghe (in un canale di supporto, in un forum, o inventale).
2. Riscrivile usando il template.
3. Per ogni campo che non puoi compilare, scrivi ??? con la domanda che faresti per riempirlo.
4. Conta i ???: sono le domande aperte che ti separano dal poter cominciare il debug.

Il principio sottostante

Un bug riproducibile è già metà risolto. Un bug non riproducibile non è un bug: è una storia.

Tutta la prima fase del debug serve a passare dalla storia al caso. Il bug report è il primo passo.

Errori frequenti del principiante

• Mescolare osservazione e ipotesi. “Penso sia il database” non va in OSSERVATO: l’osservato è ciò che si vede, non ciò che si crede.
• Omettere la versione/commit. Senza commit, due persone potrebbero star guardando codice diverso.
• Confondere “non funziona” con “non funziona come pensavo”. Se l’atteso non è scritto, l’osservato non si può giudicare.
• Saltare le evidenze. Uno screenshot da 5 KB risparmia 30 minuti di malintesi.