Cos'è lo smoke testing? I cinque minuti che decidono se vale la pena continuare a testare

Uno smoke test è un passaggio breve e superficiale sulle cose che una build deve saper fare prima che qualcuno le dedichi tempo. Si avvia. Qualcuno riesce ad accedere. La pagina principale viene disegnata. Un record si salva. Se una di queste cose non funziona, la build viene respinta e nessuno guarda oltre, perché tutto quello che verrebbe dopo sarebbe testare una build che non meritava di essere testata.

Non è approfondito di proposito. Per l’approfondimento c’è il resto della suite, e lanciarla contro una build rotta spreca una giornata a dimostrare in quaranta modi che l’accesso non funziona.

Da dove viene il nome

Dall’hardware, e la storia è letterale. Monti una scheda, le dai corrente e stai a vedere se esce fumo. Se fuma, non ha senso misurare niente: il guasto è grossolano e immediato e la scheda torna indietro. Gli idraulici usano la stessa espressione per pompare fumo nei tubi e trovare le perdite prima di chiudere i muri.

Il software ha preso in prestito il termine per lo stesso motivo. Una build che non riesce ad autenticare un utente ha prodotto fumo, e la risposta giusta è fermarsi.

Cosa non è uno smoke test

Tre termini vengono usati come sinonimi nelle riunioni quotidiane e sono tre cose diverse.

Smoke test

Questa build vale la pena di essere testata? Ampio e superficiale, eseguito per primo, a ogni build

Test di regressione

Qualcosa che funzionava ha smesso di funzionare? Profondo e lento, eseguito quando c'è tempo

Un sanity test è il terzo: un controllo stretto che una correzione specifica funzioni davvero, eseguito dopo che una modifica è entrata anziché prima che i test comincino. Lo smoke è ampio e superficiale; il sanity è stretto e superficiale; la regressione è ampia e profonda.

La differenza pratica sta in cosa succede quando uno fallisce. Un test di regressione fallito è un bug da aprire. Uno smoke test fallito è una decisione: questa build si ferma qui.

Cosa ci va dentro

La regola che tiene utile una suite di smoke è che tutto ciò che contiene deve essere qualcosa il cui fallimento renda inutile continuare a testare. È un elenco molto più corto di quanto sembri all’inizio.

Una suite tipica per un’applicazione web:

1. L'applicazione si avvia e la home page risponde 200
2. Un utente noto riesce ad accedere
3. L'elenco principale si carica e mostra dati
4. Un record può essere creato e riletto
5. Un utente autenticato riesce a uscire

Cinque controlli, un minuto o due, e nessuna affermazione sul comportamento oltre a “questo è successo”. Niente casi limite, niente messaggi di validazione, niente matrici di permessi. Tutto questo appartiene alla suite che gira dopo.

Vale la pena nominare due modi di sbagliare, perché sono entrambi comuni. Una suite che cresce fino a ottanta controlli non è più uno smoke test, è una lenta suite di regressione con il nome sbagliato, e la gente comincia a saltarla. Una suite che prova solo la home page non lo è nemmeno: passerà su una build in cui non funziona nient’altro.

Quando gira, e chi lo guarda

A ogni build, prima di ogni altra cosa, e in automatico. Uno smoke test che qualcuno deve ricordarsi di lanciare è uno smoke test che nessuno lancia il pomeriggio in cui sarebbe servito.

La sistemazione consueta è uno stadio di integrazione continua che gira dopo il deploy su un ambiente di test e vincola tutto ciò che viene dopo. Se fallisce, la pipeline si ferma, la build non viene promossa e la squadra lo sa subito: pochi minuti dopo il commit, mentre chi l’ha scritto ricorda ancora cosa ha cambiato.

Quell’immediatezza è gran parte del valore. Lo stesso difetto trovato un giorno dopo costa a qualcuno un’ora di ricostruzione prima ancora di poter cominciare.

Scrivere il primo

Parti dal percorso più breve che un utente vero fa nel tuo prodotto, e controlla solo che ogni passo si concluda.

• Scegli cinque cose, non cinquanta. Se non riesci a sostenere che un fallimento rende inutile continuare a testare, non è un controllo di smoke.
• Usa un account noto e dati noti. Uno smoke test che dipende da quello che c’è nel database in quel momento fallirà per ragioni che non riguardano la build.
• Verifica l’esistenza, non la correttezza. “Il totale della fattura è 45,00” appartiene altrove. “Una pagina di fattura è stata disegnata” appartiene qui.
• Tienilo sotto i cinque minuti. Nel momento in cui costa di più, qualcuno lo sposterà fuori dal percorso critico, e allora smetterà di vincolare qualsiasi cosa.
• Fallisci ad alta voce. Una pipeline rossa di cui nessuno viene informato è una pipeline verde con qualche passo in più.

Quando fallisce

Uno smoke test fallito non è una segnalazione di bug. È il segnale che ne serve una, e le due cose si confondono facilmente: “smoke test 3 fallito” non dice niente a chi lo prende in carico su cosa sia successo.

Quello che gli serve è la stessa cosa che serve a qualsiasi difetto: cosa ci si aspettava, cosa è successo invece, in quale ambiente, con tutto quello che il browser o il runner hanno registrato sul momento. La nostra guida per scrivere una segnalazione di bug che venga risolta è la versione lunga, e il suo modello è un file che puoi passare a chi è di turno al triage.

Per un guasto in cui qualcuno inciampa a mano, invece di uno che la pipeline ha intercettato, il contesto è la parte che di solito si perde.

La versione breve

Uno smoke test risponde a una domanda: questa build merita il tempo di qualcuno? Cinque controlli, eseguiti per primi, eseguiti sempre, e un fallimento ferma la linea invece di riempire il tracker. Tutto il resto che vuoi sapere sulla build è una domanda che vale la pena porsi solo dopo che a questa è stato risposto di sì.