Test di regressione nello sviluppo mobile — cosa sono, tipi e come si eseguono

Cosa sono i test di regressione?

I test di regressione sono un tipo di test volto a confermare che le modifiche al codice non hanno rotto le funzionalità esistenti. Il termine “regressione” significa un ritorno a uno stato peggiore — quando una funzione che funzionava nella versione precedente smette di funzionare in quella nuova. I test di regressione vengono eseguiti ripetutamente a ogni ciclo di sviluppo, distinguendoli dai test di nuove funzionalità che vengono scritti una volta sola.

La necessità dei test di regressione deriva dall'effetto delle modifiche a cascata: correggere un bug in un modulo può risolvere il problema ma rompere le funzionalità adiacenti che dipendevano da esso. Ad esempio, modificare una query SQL nel repository utenti può accelerare l'autenticazione ma rompere l'esportazione dati che utilizzava la stessa query. Un test di regressione sull'esportazione dati rileverà questa violazione prima del rilascio.

Secondo il rapporto CISQ 2023, il costo della correzione di un difetto di regressione trovato in produzione è 15 volte superiore rispetto alla fase di esecuzione automatizzata di regressione. Le aziende che investono in test di regressione automatizzati riducono la quota di difetti di regressione nei rilasci dal 25% al 5% entro un anno dall'implementazione, secondo il Capgemini World Quality Report.

Tipi di test di regressione

Esistono diversi approcci ai test di regressione che differiscono per ambito e criteri di selezione dei test. La scelta dell'approccio dipende dalle dimensioni del progetto, dalla frequenza delle modifiche e dal tempo disponibile nella pipeline CI. Di seguito sono riportati i principali tipi di test di regressione con le loro caratteristiche.

Test di regressione completi

L'esecuzione di regressione completa esegue tutti i test automatizzati del progetto senza eccezioni. Questo approccio offre la massima fiducia ma richiede notevoli risorse di calcolo e tempo. Un'esecuzione completa viene eseguita prima dei rilasci importanti — ogni 2–4 settimane. Per un'applicazione con 5000 test, un'esecuzione completa richiede da 2 a 6 ore a seconda dell'infrastruttura.

Test di regressione selettivi

L'approccio selettivo esegue solo i test correlati ai moduli modificati. Per determinare la correlazione, viene utilizzata un'analisi delle dipendenze a livello di codice: se la classe UserRepository viene modificata, vengono eseguiti i test che dipendono da UserRepository direttamente o transitivamente. Strumenti come Jacoco, Android Test Coverage e Xcode Code Coverage forniscono mappe di copertura per una selezione precisa. Un'esecuzione selettiva viene eseguita a ogni pull request e richiede 5–15 minuti.

Regressione basata sul rischio

La regressione basata sul rischio classifica i test in base alla criticità della funzionalità e alla probabilità di rottura. Le funzioni critiche — pagamenti, autenticazione, sincronizzazione — vengono testate a ogni modifica del codice. Le funzioni ausiliarie — schermata Informazioni, animazioni — vengono testate solo prima del rilascio. La classificazione viene rivista trimestralmente sulla base dei dati sugli incidenti di produzione.

Differenza tra test di regressione e retest

I concetti di test di regressione e retest vengono spesso confusi, sebbene siano processi diversi. Il retest è una riesecuzione di un test specifico che era fallito in precedenza, dopo la correzione del difetto. Lo scopo del retest è confermare che la correzione funzioni: il bug non si riproduce più. Il retest viene eseguito una volta, immediatamente dopo la correzione e la conferma della correzione da parte dello sviluppatore.

I test di regressione sono l'esecuzione di test su funzionalità esistenti che NON sono state modificate. L'obiettivo è garantire che la correzione di un difetto non abbia creato un nuovo difetto altrove. I test di regressione vengono eseguiti ripetutamente a ogni ciclo di sviluppo, indipendentemente da quali bug specifici siano stati corretti. La differenza principale: il retest verifica la correzione stessa, la regressione verifica le conseguenze della correzione.

In una pipeline CI/CD, entrambi i processi vengono eseguiti in sequenza. Dopo aver unito un pull request, viene eseguito un retest del bug specifico, seguito da un'esecuzione di regressione completa o selettiva. Secondo SmartBear (2022), separare questi processi riduce il tempo di diagnosi delle esecuzioni CI fallite del 30%, poiché il team vede immediatamente quali difetti sono correlati alla regressione e quali a correzioni non funzionanti.

Automazione dei test di regressione

L'automazione dei test di regressione è un fattore critico di successo per i progetti mobili moderni. I test di regressione manuali non si scalano: con una suite di 200 test, un'esecuzione richiede 2–3 giorni lavorativi di un ingegnere QA, rendendo impossibili le esecuzioni giornaliere. I test di regressione automatizzati vengono eseguiti in 10–60 minuti senza intervento umano, consentendo di eseguirli a ogni commit o pull request.

• Test unitari — la base della suite di regressione (70%). Vengono eseguiti in secondi, non richiedono emulatore e forniscono l'identificazione precisa della classe rotta.
• Test di integrazione — il secondo livello (20%). Verificano il livello di rete, il database e i servizi di sistema con dipendenze controllate.
• Test UI e test E2E — il vertice della piramide (10%). Coprono scenari utente critici: registrazione, pagamento, sincronizzazione.

Per mantenere aggiornata la suite di regressione, viene utilizzata l'analisi dei test: strumenti come Allure, ReportPortal e Xray monitorano i tassi di superamento, la durata e la stabilità di ogni test. I test la cui stabilità scende al di sotto del 90% (spesso si rompono a causa di modifiche ai requisiti) vengono contrassegnati come legacy e assegnati al proprietario per la revisione.

Esempio di configurazione di un test di regressione

Esaminiamo la configurazione di un test di regressione automatizzato su Android utilizzando la libreria JUnit 5 ed Espresso. L'esempio dimostra la regressione selettiva — il test verifica che, dopo il refactoring del repository utenti, la schermata del profilo non sia rotta. Per iOS, viene utilizzato XCTest con logica simile — un test ripetuto su uno scenario chiave.

Android: test di regressione del profilo

Il test utilizza MockWebServer per emulare il server e verifica il percorso completo: caricamento dei dati utente, visualizzazione sulla schermata del profilo e gestione degli errori quando il server non è disponibile. Tali test vengono inclusi nella suite di regressione ed eseguiti a ogni modifica nel modulo del profilo.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Errore di caricamento").assertIsDisplayed()
    }
}

iOS: test di regressione con XCTest

Per iOS, il test di regressione utilizza XCTestExpectation per la verifica asincrona dell'aggiornamento dell'interfaccia utente dopo aver ricevuto dati dall'API. Il test emula una risposta di rete e verifica che gli elementi dell'interfaccia siano stati aggiornati correttamente.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Strategia per costruire una suite di regressione

Costruire una suite di regressione efficace è un processo iterativo basato su dati di difetti e modifiche al codice. La strategia iniziale consiste nell'includere tutti i test esistenti nella suite di regressione ed eseguire un passaggio completo prima di ogni rilascio. Con la crescita della base di test (oltre 2000 test), un'esecuzione completa diventa troppo lunga e diventa necessario un approccio selettivo.

La seconda fase — implementazione di strumenti di analisi delle dipendenze: Jacoco per Android, Xcode Test Plan per iOS. Questi strumenti costruiscono una mappa “test — classe — metodo” e consentono di determinare quali test sono influenzati da una modifica specifica. Un'esecuzione selettiva basata sull'analisi della copertura riduce il tempo di esecuzione del 60–80% mantenendo il 95% di efficacia nel rilevamento delle regressioni, secondo Spotify Engineering (2022).

La terza fase — monitoraggio continuo e ottimizzazione. I test che non sono falliti in 6 mesi vengono spostati in una suite a priorità bassa. I test che falliscono più di una volta al mese sono candidati per la revisione: o rilevano problemi reali (necessitano di una correzione) o sono troppo fragili (richiedono stabilizzazione). Una revisione trimestrale della suite di regressione è una pratica standard per mantenere la sua efficacia e velocità di esecuzione.