Glossario · Fondamenti del testing
Test di regressione
In inglese: Regression testing
Detto anche: regression test, suite di regressione, collaudo di regressione
Definizione
Rieseguire i test esistenti dopo una modifica per confermare che ciò che già funzionava funziona ancora e che la correzione o la nuova funzionalità non ha rotto altro.
Il test di regressione (regression testing) verifica che una modifica non abbia rotto qualcosa che prima funzionava. Una “regressione” è una funzionalità che funzionava in una build precedente e ora non funziona più. La intercetti rieseguendo i test sul comportamento esistente dopo ogni bug fix, nuova funzionalità, refactoring, aggiornamento di dipendenze o cambio di configurazione.
Esempio
Un team aggiunge al checkout l’opzione “paga con carta regalo”. La nuova funzionalità ha i suoi test. Il test di regressione pone una domanda diversa: i pagamenti con carta, i codici sconto, il calcolo delle tasse e le email degli ordini si comportano ancora esattamente come prima? Una modifica condivisa al modulo di calcolo dei prezzi potrebbe facilmente romperne uno qualsiasi senza toccare il nuovo percorso di codice.
Scegliere cosa eseguire
Eseguire tutti i test a ogni commit è la strategia più semplice e, con una suite automatizzata veloce, spesso è quella giusta. Quando la suite completa è troppo lenta o in parte manuale, i team selezionano:
- Per rischio. I flussi critici per il business (registrazione, pagamento, esportazione dei dati) vengono sempre eseguiti.
- Per impatto. Le aree che condividono codice, dati o servizi con la modifica.
- Per storico. I moduli che hanno già avuto regressioni tendono ad averne di nuovo.
Una suddivisione comune è un sottoinsieme di regressione veloce su ogni pull request e la suite completa di notte o prima di un rilascio.
Perché è la prima cosa che i team automatizzano
I test di regressione eseguono gli stessi passi con gli stessi risultati attesi più e più volte, che è esattamente ciò in cui l’automazione eccelle. La regressione manuale cresce a ogni rilascio mentre il tempo disponibile no, quindi è la prima cosa a essere tagliata. Una suite di regressione automatizzata in CI trasforma il “abbiamo rotto qualcosa?” da una settimana di verifiche manuali nel risultato di una pipeline.
Errori comuni
- Trattare la suite come se si potesse solo aggiungere. Test obsoleti e duplicati rallentano ogni esecuzione. Rivedi e sfoltisci.
- Tollerare i test flaky. Se i fallimenti vengono rieseguiti di routine finché non diventano verdi, anche le regressioni reali spariscono a forza di riesecuzioni.
- Testare solo dalla UI. La maggior parte della copertura di regressione costa meno ed è più stabile a livello unit e API.