Test di regressione: assicurazione contro la rottura di ciò che già ha funzionato

La peggiore categoria di bug non è quella che introduci in una nuova funzionalità. È ciò che fa risorgere una vecchia funzionalità, che funzionava perfettamente finché qualcuno non ha cambiato qualcos'altro.

È una scena familiare. Il team risolve un problema, lo implementa, festeggia e tre giorni dopo scopre che quella soluzione ha interrotto silenziosamente un flusso che nessuno aveva pensato di controllare. Il cliente lo trova per primo. La fiducia nel sistema e nella squadra subisce un duro colpo.

Questo fenomeno ha un nome: regressione. E' il sistema che va indietro. E l’insieme di pratiche esistenti per evitarlo è il test di regressione, probabilmente il tipo di test più sottovalutato e più prezioso di tutti.

Cos'è il test di regressione

Il test di regressione è la riesecuzione dei test su funzionalità già esistenti, per garantire che una modifica recente non rompa nulla di ciò che già funzionava. La parola chiave è “già esisteva”. Non controlla ciò che hai appena costruito; controlla tutto ciò che potresti aver rotto accidentalmente durante la costruzione.

La premessa è una scomoda verità del software: ogni sistema è una rete di dipendenze, molte delle quali invisibili. La modifica di un punto può influenzarne un altro a chilometri di distanza nel codice. Nessuno può, solo pensando, prevedere tutte le conseguenze di un cambiamento. Il test di regressione è la rete che cattura ciò che la tua testa non aveva previsto.

Perché ogni cambiamento è un rischio

Il software non è statico. Cambia continuamente, correzioni, funzionalità, aggiornamenti della libreria, aggiustamenti della configurazione. E ogni cambiamento, per quanto piccolo possa sembrare, comporta il rischio di regressione.

La cosa pericolosa è che l’entità del cambiamento non predice l’entità del danno. Una modifica a una linea può interrompere un flusso critico se quella linea si trova in un punto condiviso da molte parti del sistema. Ho visto correzioni banali causare incidenti più grandi di intere riscritture.

Questo è il paradosso della manutenzione: più un sistema cresce e matura, più diventa prezioso, e più diventa rischioso cambiarlo, perché c’è altro che può rompersi. Senza una rete di regressione, il team arriva a un punto in cui ha paura di toccare il prodotto stesso. Il sistema "si blocca" non perché sia pronto, ma perché è troppo pericoloso toccarlo.

Perché la regressione richiede l'automazione

È possibile eseguire la regressione manualmente, rieseguendo manualmente i flussi principali dopo ogni modifica. Funziona quando il sistema è piccolo. Smette di funzionare rapidamente.

Il problema è di scala e di ripetizione. La regressione deve essere eseguita ad ogni cambiamento, su un insieme che non fa che crescere. Farlo manualmente, ripetutamente, è costoso, lento e, peggio ancora, soggetto alla fatica umana. Il tester manuale, alla centesima volta che controlla lo stesso flusso, presta meno attenzione. È naturale.

Questo è il motivo per cui la regressione è il caso d'uso per eccellenza dell'automazione. Un test automatizzato non si stanca, non salta passaggi ed esegue in pochi secondi ciò che richiederebbe ore con un test manuale. È esattamente il tipo di verifica ripetitiva e oggettiva che le macchine fanno meglio delle persone. La suite di regressione automatizzata è ciò che ti consente di modificare frequentemente il sistema senza paura.

Cosa c'è nella suite di regressione

Non è necessario che tutto sia nella suite. Cercare di coprire ogni percorso possibile crea una suite enorme, lenta e costosa da mantenere, che il team finisce per ignorare.

La regola pratica è dare priorità in base al rischio e alla frequenza. Entrano in flussi critici per l’azienda, quelli il cui guasto provoca danni reali o perdita di fiducia. Ci sono anche aree che storicamente si sono rotte: ogni bug risolto dovrebbe diventare un test di regressione, per garantire che non si ripresenti. Questa è una delle migliori abitudini che una squadra può adottare.

Ciò che tende ad essere tralasciato, o ad avere una priorità inferiore, sono le funzionalità periferiche, usate raramente e a basso impatto. La copertura completa non è l’obiettivo; la protezione di ciò che conta è.

Gli errori che rendono inutile la regressione

Il primo errore è lasciare marcire la suite. I test di regressione riflettono il comportamento previsto del sistema. Quando il comportamento cambia legittimamente e i test non vengono aggiornati, falliscono perché non sono aggiornati, non a causa di un bug reale. La squadra impara a ignorare i fallimenti e la rete smette di catturare qualsiasi cosa.

Il secondo è tollerare test intermittenti. Un test di regressione che a volte supera e a volte fallisce senza motivo è veleno: diluisce la credibilità dell’intera suite. Quando il rosso smette di significare "qualcosa si è rotto", la regressione ha perso la sua funzione.

Il terzo è eseguire la regressione troppo tardi. Se la suite viene eseguita solo il giorno prima del rilascio, i problemi si accumulano e diventa costoso monitorarli. L'ideale è correre ad ogni modifica, sul trasportatore di integrazione, in modo che la rottura venga rilevata vicino alla causa, quando è ancora economico ripararla.

La regressione è ciò che dà la libertà di evolversi

Si ritiene erroneamente che i test di regressione siano un blocco, una burocrazia che ritarda la consegna. E' il contrario. Una buona suite di regressione è ciò che offre al team la libertà di fornire risultati rapidamente.

Senza di essa ogni cambiamento richiede cautela, controllo manuale, paura. Con esso, lo sviluppatore modifica il codice, esegue la suite e, in pochi minuti, sa se qualcosa si è rotto. Questa fiducia è ciò che ti consente di mantenere il ritmo di consegna man mano che il sistema cresce. La regressione non frena la velocità; È ciò che rende la velocità sostenibile.

Nei sistemi che supportano servizi critici, pubblici o privati, questo è ancora più decisivo. La capacità di far evolvere un sistema essenziale senza il timore di stravolgere ciò che già funziona è, in sostanza, una capacità di governance. Il test di regressione è uno degli strumenti che lo rendono possibile.

Alla fine, ogni software stabile è un sistema che qualcuno ha avuto il coraggio di non lasciare inattivo. La regressione è ciò che rende questo coraggio responsabile piuttosto che avventato.

Se il tuo team evita già di toccare parti del sistema per paura di rompere qualcosa, questa paura è un sintomo di una mancanza di rete di regressione ed è affrontabile. Ho altri articoli sul blog su qualità, automazione e manutenzione del software che parlano di questo.