Regressione — cos’è, perché si verifica e come testarla

Cos’è la Regressione nello Sviluppo

Regressione è una situazione in cui una funzionalità che funzionava in una versione precedente smette di funzionare dopo aver apportato modifiche. La modifica può essere qualsiasi cosa: correzione di bug, aggiunta di una nuova funzionalità, refactoring, aggiornamento di una libreria o persino un cambiamento di configurazione. La regressione è il principale nemico della stabilità: ogni modifica rischia di rompere qualcosa che è già stato verificato e rilasciato.

Il termine deriva dal testing: il test di regressione è la riesecuzione dei test esistenti dopo ogni modifica per verificare che la vecchia funzionalità non sia stata rotta. Se un test che in precedenza passava fallisce, si è verificata una regressione. In senso più ampio, la regressione non è solo un fallimento del test, ma qualsiasi degrado del comportamento notato dall’utente o dal QA. Secondo Tricentis State of Testing 2023, le regressioni costituiscono il 35–45% di tutti i bug trovati in produzione.

Ciò che distingue una regressione da un bug comune è il contesto temporale: un bug potrebbe essere sempre esistito, mentre una regressione è sempre il risultato di una modifica. Questa è una distinzione importante perché trovare la causa di una regressione inizia analizzando cosa è cambiato tra “funzionava” e “hnon funziona più”. Git bisect è lo strumento standard per trovare il commit che ha causato la regressione.

Tipi di Regressioni ed Esempi

Regressione locale — una modifica nel modulo A rompe la funzionalità nello stesso modulo A. Esempio: uno sviluppatore riscrive una funzione di ordinamento e questa smette di gestire correttamente un array vuoto. La regressione locale è la più facile da rilevare e correggere perché causa ed effetto sono vicini.

Regressione remota — una modifica nel modulo A rompe la funzionalità nel modulo B, che non è direttamente collegato dal codice ma lo è dai dati o dalla temporizzazione. Esempio: cambiare lo schema del database nel modulo “Utenti” rompe un report nel modulo “Analytics” che utilizza la stessa tabella. Le regressioni remote sono le più insidiose: lo sviluppatore non sospetta che la sua modifica influenzerà un altro modulo.

Regressione da effetto collaterale — una modifica a un effetto collaterale (logging, caching, invio di notifiche) rompe il comportamento atteso. Esempio: uno sviluppatore aggiunge caching per accelerare le prestazioni, ma a causa di cache obsoleta, gli utenti vedono dati vecchi. Le regressioni da effetto collaterale sono difficili da rilevare con test automatizzati perché gli effetti collaterali spesso non sono coperti dai test.

Regressione di prestazioni — il codice continua a funzionare correttamente funzionalmente ma è più lento di prima. Esempio: un nuovo algoritmo di crittografia produce gli stessi risultati, ma il tempo di esecuzione è aumentato da 2 ms a 200 ms. Le regressioni di prestazioni non vengono rilevate dai normali test unitari — sono necessari benchmark e profiling.

Perché si Verificano le Regressioni

La prima causa è l’accoppiamento del codice. Più i moduli dipendono l’uno dall’altro, maggiore è la probabilità che una modifica in uno causi una regressione nell’altro. Antipattern classici: God Object (un oggetto che fa tutto), Shotgun Surgery (una modifica in un punto richiede modifiche in una dozzina di punti), dipendenza circolare. Ridurre l’accoppiamento è una questione di architettura: principi SOLID, Dependency Injection, architettura esagonale.

La seconda causa è la mancanza di test per la funzionalità modificata. Se il codice non è coperto da test, lo sviluppatore viene a conoscenza di una regressione solo dal QA o dagli utenti. Secondo Google Testing Blog, i progetti con copertura dei test >75% hanno 5 volte meno regressioni rispetto ai progetti con copertura <25%. Il TDD (Test-Driven Development) garantisce che i test siano scritti prima del codice, non “quando si ha tempo”.

La terza causa è il fattore umano. Lo sviluppatore non conosce la funzionalità correlata, non comprende tutte le dipendenze o è semplicemente di fretta. Il motivo è la mancanza di condivisione della conoscenza della codebase. Soluzioni: revisione del codice con sviluppatori di altri moduli, programmazione in coppia, documentazione dell’architettura. Il bus factor del progetto è inversamente proporzionale al numero di decisioni architetturali documentate.

Test di Regressione e il suo Ruolo

Il test di regressione è il processo di riesecuzione dei test esistenti dopo ogni modifica per verificare che la vecchia funzionalità non sia stata danneggiata. È l’unico modo per garantire che una nuova modifica non abbia compromesso il codice esistente. Senza test di regressione, ogni rilascio è una lotteria: lo sviluppatore spera di non aver rotto nulla ma non può confermarlo.

Il test di regressione manuale è l’approccio più costoso e meno efficace. Con la crescita di un progetto, il numero di scenari di test di regressione cresce linearmente, mentre il tempo di esecuzione manuale cresce esponenzialmente. Dopo 2–3 anni di sviluppo, la regressione manuale può richiedere 2–3 settimane, rendendo impossibili rilasci frequenti. L’unica soluzione è l’automazione.

Il test di regressione automatizzato è suddiviso in livelli secondo la piramide del testing:

• Test unitari — veloci, isolati, coprono funzioni e metodi individuali
• Test di integrazione — verificano l’interazione tra moduli, database, servizi esterni
• Test E2E — verificano scenari utente completi attraverso UI o API
• Test snapshot — confrontano l’output corrente di un componente con un riferimento

Secondo Google Testing Blog, il rapporto ottimale è 70% test unitari, 20% test di integrazione, 10% E2E. Discostarsi da questa proporzione riduce l’efficacia del test di regressione: troppi test E2E rallentano la pipeline, troppo pochi test unitari lasciano micro-bug non rilevati.

Strategie per Automatizzare il Test di Regressione

La prima strategia è la Regressione Completa. Vengono eseguiti tutti i test del progetto. L’approccio più affidabile ma anche più lento. Adatto a progetti piccoli (fino a 10.000 test, tempo di esecuzione <30 minuti). Per progetti grandi, la regressione completa può richiedere ore, rendendo la pipeline CI/CD poco pratica.

La seconda strategia è la Regressione Selettiva. Vengono eseguiti solo i test relativi al codice modificato. Un grafico delle dipendenze del codice viene utilizzato per determinare le relazioni. Strumenti: Bazel (Google), Nx (JavaScript), sbt (Scala). La regressione selettiva fa risparmiare il 60–80% del tempo di esecuzione ma richiede una costruzione accurata del grafico delle dipendenze — gli errori portano a regressioni non rilevate.

La terza strategia è la Regressione Priorizzata. Tutti i test sono classificati per priorità: percorso critico (scenari utente più importanti), alto rischio (codice con storico di bug), codice modificato (codice interessato dalla modifica). I test con priorità più alta vengono eseguiti per primi — se superano, lo sviluppatore riceve un feedback rapido. Esecuzione con time-box: i test critici vengono verificati in 10 minuti, il resto viene eseguito in background.

Come Prevenire le Regressioni in un Progetto

Il primo e più importante passo è una cultura della scrittura dei test. Ogni modifica dovrebbe essere accompagnata da un test che verifichi che la modifica funzioni e da un test che verifichi che nulla sia stato rotto. Il TDD (Test-Driven Development) dà i migliori risultati: lo sviluppatore scrive prima un test che fallisce, poi il codice che lo supera. Questo garantisce che il test esista prima del codice.

Il secondo passo è una pipeline CI/CD con esecuzione obbligatoria dei test. Una pull request non può essere unita finché tutti i test non sono superati. I test non possono essere “saltati” per urgenza — le modifiche urgenti passano attraverso una suite di test accelerata ma obbligatoria. Secondo Google DevOps Research, i team con CI/CD obbligatorio hanno 3 volte meno regressioni in produzione.

Il terzo passo è il monitoraggio in produzione. Anche i migliori test non garantiscono una protezione al 100% dalle regressioni. Gli strumenti di observability (Sentry, Datadog, New Relic) dovrebbero monitorare le metriche chiave dopo ogni deployment: tasso di errore, latenza, throughput. Il rollback automatico al superamento delle soglie è una rete di sicurezza se una regressione raggiunge la produzione.

Il quarto passo è la revisione del codice con mentalità di regressione. Il revisore dovrebbe chiedersi: “Quali altri moduli potrebbero rompersi a causa di questa modifica?”. Non basta verificare che il codice sia corretto — bisogna verificare che non comprometta le funzionalità correlate. La checklist di revisione del codice dovrebbe includere una voce “verifica regressione nei moduli correlati”.