Cos'è il test di regressione? Verificare che la correzione non abbia rotto altro

Il test di regressione serve a verificare che quello che funzionava funzioni ancora, dopo una modifica. Non la modifica in sé - quella la si prova mentre la si scrive - ma tutto ciò che le sta intorno, che nessuno ha toccato e che nessuno si aspettava fosse coinvolto.

Il nome dice tutto. Una regressione è un passo indietro: una funzione che nella versione precedente andava e in questa no. Questi test esistono perché il software è collegato in modi che nessuno tiene a mente, e il codice sconto che qualcuno ha sistemato martedì condivide una funzione con il calcolo delle imposte che nessuno guarda da marzo.

Perché è il lavoro di qualcuno

Ogni modifica ha un raggio d’azione più ampio del suo diff. Una funzione condivisa, una colonna del database letta in sei punti, una regola CSS che si rivela portante per una pagina che l’autore non aveva mai aperto.

Il guasto che tutto questo previene è preciso e costoso: una versione che corregge un difetto segnalato e ne introduce due che nessuno ha segnalato. Quelli costano molto più dell’originale, perché nessuno li sta cercando. Il difetto segnalato aveva qualcuno che aspettava la correzione; i nuovi li scoprono i clienti, giorni dopo, senza sapere che cosa sia cambiato.

Che cosa riprovare davvero

Non puoi riprovare tutto a ogni modifica, e le squadre che ci provano si ritrovano con una suite così lenta che viene saltata. Il test di regressione è un problema di selezione, e la selezione si fa sul rischio.

Vale la pena riprovarlo a quasi ogni modifica:

• I percorsi che portano soldi. Registrazione, accesso, carrello, pagamento. Tutto il resto può aspettare lunedì; questi no.
• Quello che la modifica tocca davvero, più tutto ciò che condivide con essa una funzione, una tabella o un template.
• Qualsiasi cosa si sia già rotta. Un difetto tornato una volta tornerà ancora, e un bug che è regredito è il miglior argomento per un test permanente.
• Le integrazioni che non controlli. Tutto ciò che raggiunge un altro servizio si guasta per motivi che con la tua versione non c’entrano nulla.

Non ne vale la pena ogni volta: schermate di impostazioni usate di rado, strumenti di amministrazione con due utenti, qualsiasi cosa il cui guasto qualcuno noterebbe e segnalerebbe senza danni.

Dove finisce lo smoke test e comincia questo

Vengono posti in momenti diversi e rispondono a domande diverse.

Smoke test

Questa build vale la pena di essere testata? Cinque controlli, minuti, eseguito per primo, a ogni build

Test di regressione

Qualcosa che funzionava ha smesso di funzionare? Centinaia di controlli, più lungo, eseguito una volta che la build si è dimostrata valida

Far girare una suite di regressione contro una build che non riesce a far accedere un utente spreca un’ora a dimostrarlo in quattrocento modi. Lo smoke test viene prima esattamente per questo.

A mano o automatizzato

L’automazione è la risposta ovvia e quella incompleta.

Automatizza ciò che è stabile, prezioso e noioso: i percorsi del denaro, i contratti delle API, i calcoli con ingressi noti e risposte note. Quelli vale la pena scriverli una volta e farli girare per sempre, e sono i test che prendono una regressione alle tre di notte senza che nessuno stia guardando.

Tieni una persona per ciò che uno script non sa giudicare. Se il layout è sbagliato e non soltanto diverso. Se un messaggio di errore ha senso. Se il flusso dà ancora l’impressione di funzionare. Un confronto di screenshot ti dirà che undici pixel si sono spostati; non ti dirà che il pulsante è finito sotto la piega sul portatile più diffuso fra i tuoi utenti.

La maggior parte delle squadre finisce con una suite automatizzata per i percorsi che non devono rompersi e un breve passaggio manuale sulle aree toccate dalla versione.

Come una suite si guasta

In tre modi, tutti comuni, e ognuno finisce con la suite ignorata.

Diventa lenta. Una suite che impiega novanta minuti gira di notte invece che a ogni modifica, e su una regressione trovata la mattina dopo si è già costruito sopra.

Diventa instabile. Un test che fallisce una volta su dieci insegna a tutti a rilanciarlo, e l’abitudine a rilanciare è indistinguibile dal non avere il test. Una cosa davvero rotta si nasconde nel rumore di quelle che sono soltanto inaffidabili.

Cresce e basta. Si aggiungono test per ogni difetto e non se ne toglie nessuno, finché metà della suite copre comportamenti che il prodotto non ha più. Cancellare i test fa parte del mantenerli.

Quando salta fuori una regressione

Un test di regressione fallito è una segnalazione di bug ancora da scrivere, e parte con più informazioni di quante ne riceva la maggior parte delle segnalazioni: sai che prima funzionava, e spesso sai in quale versione ha smesso.

Dillo. “Funzionava in 4.2.0, fallisce in 4.3.0” trasforma un’indagine in un diff. È la frase più utile di una segnalazione di regressione e quella che più spesso manca, perché chi la scrive dà per scontato che lo sappiano tutti.

Per una regressione in cui qualcuno inciampa a mano, invece di una presa dalla suite, il contesto è la parte che di solito si perde.

Il resto di ciò che serve a una buona segnalazione sta nella guida alla segnalazione di bug, e il suo modello ha una riga per la versione in cui funzionava.

In breve

Il test di regressione chiede se la modifica che hai fatto ne ha rotta una che non hai fatto. Scegli che cosa riprovare in base al rischio e non all’ambizione, metti i percorsi del denaro sotto automazione, tieni una persona per i giudizi che uno script non può dare, e cancella i test con la stessa disinvoltura con cui li aggiungi. Quando ne trovi una, di’ in quale versione funzionava l’ultima volta.