Tassonomia: regressione, bug nuovo, limitazione, flaky

In parole semplici

Anche tra i bug “veri” non sono tutti uguali. Un bug appena nato in una versione che funzionava si tratta diversamente da un bug presente da sempre, e un bug “che a volte si vede” merita una corsia tutta sua. Questa lezione introduce quattro etichette che diventano i nomi delle corsie.

Parole nuove

• regressione: comportamento che funzionava in una versione precedente e ora non funziona più.
• bug nuovo: difetto che non è mai stato corretto perché non è mai esistita una versione “sana”.
• limitazione: comportamento sgradevole ma documentato (già visto nel modulo 0).
• flaky bug: difetto che si manifesta in modo intermittente, senza una causa scatenante chiara.

Cosa impari

• Assegnare a un bug una delle quattro etichette in meno di un minuto.
• Capire perché ognuna porta a un percorso diverso (rollback? feature flag? quarantena?).
• Riconoscere quando l’etichetta sbagliata fa perdere giorni.

Le quattro etichette in dettaglio

Regressione

Esisteva una versione che funzionava. Indizi tipici:

• “Funzionava la settimana scorsa.”
• “Dopo l’aggiornamento.”
• “Da quando abbiamo deployato X.”

Cosa attiva: indagine sul diff tra versioni. git log e git bisect (modulo 4) sono gli strumenti naturali. Spesso la soluzione più rapida non è capire la causa: è fare git revert del commit incriminato e poi indagare con calma.

Bug nuovo

Non c’è mai stata una versione “giusta”. È una funzionalità rotta dalla nascita. Indizi:

• “L’ho appena scritto.”
• “Non ha mai funzionato.”
• Codice ancora dietro a un feature flag interno.

Cosa attiva: indagine “frontale”, lettura del codice, test mirati. Non c’è un commit da invertire perché il bug non è una regressione: è una funzione mai stata corretta.

Limitazione (documentata)

Il comportamento è “noto e accettato”. Indizi:

• “Lo dice anche la documentazione.”
• “È così di proposito.”
• “Funziona solo fino a X.”

Cosa attiva: niente codice, almeno non subito. Si valuta se la limitazione vale ancora o se vada cambiata. Se la documentazione mente, il vero bug è nella documentazione.

Flaky bug

Si vede a volte. La stessa azione, ripetuta, dà esito diverso. Indizi:

• “A volte sì, a volte no.”
• “Solo quando la rete è lenta.”
• “Solo se ricarico due volte.”

Cosa attiva: indagine sulle condizioni nascoste (rete, timing, dati, cache, race condition — modulo 7). I flaky bug sono i più costosi: vanno isolati con cura prima di toccare il codice.

Tabella decisionale

Etichetta	Domanda chiave	Strumento di prima linea	Tentativo immediato
regressione	quando ha smesso di funzionare?	git bisect	git revert del commit
bug nuovo	è mai esistita una versione giusta?	code review	test che fissa il comportamento atteso
limitazione	è scritto da qualche parte?	documentazione	leggere prima di toccare il codice
flaky	cosa cambia tra “sì” e “no”?	log + ripetizione	catturare la run in cui fallisce

La regola del “prima di indagare”

Prima di partire con l’indagine, dichiara l’etichetta e la prova che la giustifica.

Esempio buono:

Etichetta: regressione. Prova: il commit a1b2c3 (release 2.3.0) include il fix #412 e da quel momento i test di carrello falliscono.

Esempio cattivo:

Etichetta: regressione. Prova: “secondo me”.

Esercizio guidato

Prendi sei segnalazioni recenti (anche dal tuo issue tracker simulato) e assegna a ciascuna:

• etichetta;
• severità (critica/alta/media/bassa);
• priorità (subito/sprint/backlog);
• prossimo passo (es. “git bisect”, “leggere doc”, “fissare condizione”).

Una matrice 6×4 sarà la tua matrice di triage per i primi giorni di laboratorio.

Errori frequenti del principiante

• Trattare ogni bug come regressione. Se non c’è mai stata una versione sana, git bisect non porta da nessuna parte.
• Ignorare i flaky. Marcarli “non riproducibile” e chiuderli. Tornano sempre, peggio di prima.
• Saltare la lettura della documentazione. Spesso il “bug” è già scritto come limitazione.
• Etichettare dopo aver corretto. L’etichetta serve prima, per scegliere il percorso. Dopo è solo archeologia.