Risposta.

Storia della domanda:

Il testing smoke ("testing di fumo") è nato come un modo veloce per verificare la funzionalità del sistema dopo la build. Il suo scopo è garantire che le funzioni critiche funzionino e che l'applicazione sia in linea di massima adatta per verifiche più approfondite. Nel testing manuale, i test smoke vengono generalmente eseguiti subito dopo il deployment di una nuova versione del prodotto.

Problema:

La difficoltà principale è il tempo limitato e la necessità di selezionare controlli realmente importanti. Spesso i tester controllano troppo (sprecando risorse) o trascurano aspetti critici, il che può portare a "bug" in produzione.

Soluzione:

Una corretta organizzazione del testing smoke consiste nella selezione di un insieme minimo di scenari che coprono i flussi utente più importanti. Questi controlli devono essere chiari, rapidi e riproducibili. Ad esempio:

- Accesso riuscito dell'utente al sistema
- Capacità di eseguire la funzione principale (ad esempio, effettuare un acquisto)
- Esecuzione del pagamento e ricezione della conferma

Caratteristiche chiave:

I test smoke coprono solo funzioni vitali
Esecuzione rapida, fondamentale in caso di rilasci frequenti
Tutti gli scenari vengono eseguiti manualmente seguendo una checklist approvata in anticipo

Domande trabocchetto.

Si può considerare il testing smoke come una sostituzione adeguata del testing regressivo?

No, il testing smoke è orientato solo a "funziona — non funziona" per le funzioni chiave. Per rilevare bug gravi ma non evidenti è sempre necessario un testing regressivo completo.

Cosa fare se almeno un test smoke non viene superato? Dovrebbe continuare il testing?

No, non ha senso continuare il testing — il team segnala il problema, il rilascio è bloccato finché il bug non viene corretto.

I test smoke dovrebbero includere controlli per scenari edge-case?

No, i test smoke non sono destinati a controllare casi estremi. Servono solo a confermare la possibilità stessa di funzionamento delle funzioni principali del prodotto.

Errori comuni e anti-pattern

Esecuzione di test eccessivi che non sono critici per la funzionalità
Mancanza di documentazione sui test smoke (il tester "tiene tutto a mente")
Ignorare problemi evidenti per "rendicontazione"

Esempio della vita reale

Caso negativo

Il test smoke è stato effettuato su una checklist ampia, includendo funzioni di poco significato. Ci è voluto molto tempo, quindi il rilascio è stato ritardato di mezza giornata.

Vantaggi:

Rilevati diversi bug non evidenti

Svantaggi:

Ritardo nel rilascio
Risorse e tempo spesi per controlli di poco significato

Caso positivo

Il test smoke si è concentrato solo sugli scenari più critici. È stato rapidamente identificato un bug bloccante e comunicato al team — il rilascio è stato sospeso fino alla correzione.