Sanity testing

Il sanity testing è una verifica rapida e mirata che una modifica specifica funzioni e che l’area circostante si comporti ancora in modo sensato. Si fa dopo un bug fix o una modifica minore su una build già ragionevolmente stabile. Se il sanity check fallisce, la build torna allo sviluppo senza sprecare tempo in un’intera esecuzione di regressione.

Esempio

Un bug report dice che l’email di “Password dimenticata” non viene inviata quando l’indirizzo contiene un segno più (ana+test@example.com). Lo sviluppatore rilascia una correzione. Un sanity check prevederebbe di:

1. Richiedere un reset per ana+test@example.com e verificare che l’email arrivi.
2. Richiedere un reset per un indirizzo normale e verificare che funzioni ancora.
3. Seguire il link di reset e verificare che la nuova password venga accettata.

Tutto qui. Nessuno controlla il carrello o il modulo di reportistica in questa fase. Se questi controlli passano, la build prosegue verso il test di regressione.

Sanity testing e smoke testing a confronto

	Sanity testing	Smoke testing
Ambito	Ristretto e abbastanza profondo, una funzionalità o una correzione	Ampio e superficiale, l’intera applicazione
Quando scatta	Una correzione specifica o una piccola modifica	Ogni nuova build
Stato della build	Già abbastanza stabile	Sconosciuto, forse rotta
Forma	Spesso senza script, eseguito da un tester	Di solito una suite scriptata e automatizzata

Alcuni team descrivono il sanity testing come un sottoinsieme del test di regressione focalizzato sull’area modificata. È un modo ragionevole di vederlo.

Una nota sulla terminologia

Le definizioni variano tra aziende e libri di testo, e alcuni team usano “smoke” e “sanity” come sinonimi. A un colloquio, spiega la distinzione qui sopra, poi aggiungi che nella pratica conta che il team sia d’accordo su cosa copre ogni verifica e quando viene eseguita. Essere precisi riconoscendo l’ambiguità fa una figura migliore che insistere su un unico libro di testo.