Che cos'è un bug e che cosa non lo è

In parole semplici

Un bug è uno scostamento misurabile tra ciò che il programma promette di fare e ciò che fa davvero. Non ogni cosa che ci fa storcere il naso davanti a uno schermo è un bug: a volte è una limitazione dichiarata, a volte una richiesta di funzionalità travestita da segnalazione, a volte un malinteso d’uso.

Questa è la prima lezione del modulo Fondamenta del debug. Imparare a separare queste categorie ti fa risparmiare ore: si corregge solo ciò che davvero deve essere corretto.

Parole nuove

• bug: comportamento del programma che contraddice una specifica esistente.
• limitazione: comportamento sgradevole ma documentato e accettato.
• richiesta di funzionalità (feature request): qualcosa che il programma non fa, e mai ha promesso di fare.
• malinteso d’uso (user error): il programma fa esattamente ciò che è stato chiesto, ma chi lo usa si aspettava altro.
• specifica: descrizione scritta o implicita di come dovrebbe comportarsi il programma.

Cosa impari

• Riconoscere quattro famiglie di segnalazione frequenti.
• Capire perché senza una specifica anche un vero bug rischia di sembrare opinione.
• Dare un primo nome a un problema prima di sceglierne la soluzione.

Le quattro famiglie

1. Bug

C’è una specifica (anche implicita) e il programma non la rispetta.

“Cliccando su ‘Salva’ la pagina mostra ‘Salvato’ ma il dato non appare al ricaricamento.”

Promessa: “Salva” persiste il dato. Realtà: non persiste. Differenza misurabile → bug.

2. Limitazione

Il comportamento è strano, ma è stato dichiarato.

“L’export CSV supporta solo i primi 1000 record.”

Se è scritto nella documentazione, non è un bug. È una scelta. Può diventare bug solo se la documentazione promette diversamente.

3. Richiesta di funzionalità

Manca qualcosa che nessuno ha mai promesso.

“Non c’è un pulsante per esportare in PDF.”

Se il prodotto non ha mai detto di farlo, non è rotto. È una richiesta nuova, va trattata come tale (priorità, design, sviluppo) — non come fix.

4. Malinteso d’uso

Il programma fa quello che è stato chiesto, ma l’utente si aspettava altro.

“Ho cancellato il file e ora non lo trovo più.”

Il programma ha eseguito l’ordine. Serve chiarire l’interfaccia o la comunicazione, non riscrivere il codice.

Perché la distinzione conta

Ogni categoria attiva un percorso diverso:

• bug → riproduzione, indagine, fix, regressione.
• limitazione → eventuale modifica della documentazione o della scelta di prodotto.
• richiesta → backlog, priorità, design.
• malinteso → migliorare UX, microcopy, onboarding.

Confondere le categorie significa scrivere codice per problemi che non sono di codice, o ignorare bug perché sembrano “richieste”.

Esercizio guidato

1. Apri un forum pubblico di un software che usi (issue tracker di un progetto open source, store di app, recensioni).
2. Scegli dieci segnalazioni e per ognuna scrivi una riga: categoria — motivazione in una frase.
3. Per le segnalazioni ambigue, annota la specifica mancante che ti permetterebbe di decidere.

Esempio:

#	Segnalazione	Categoria	Motivazione
1	”Salva non salva”	bug	promessa esplicita disattesa
2	”Manca export PDF”	richiesta	nessuna promessa precedente
3	”Lento con 50.000 righe”	limitazione	documentato come “ottimizzato fino a 10k”
4	”Ho perso il file dopo aver cliccato Elimina”	malinteso	conferma di eliminazione visibile, comportamento corretto

Cosa portare alla prossima lezione

• La tua tabella con dieci segnalazioni classificate.
• I tre criteri che ti hanno aiutato a decidere quando il dubbio era forte.
• Una segnalazione su cui hai cambiato idea e perché.

Errori frequenti del principiante

• Trattare ogni lamento come bug. Spreca tempo e svuota la priorità reale.
• Cercare la causa prima di nominare il problema. Senza categoria, qualsiasi indagine si perde.
• Dare per scontata la specifica. Se non è scritta da nessuna parte, scrivila tu prima di proseguire.