Regressietesten in mobiele ontwikkeling — wat het is, typen en hoe het wordt uitgevoerd

Wat zijn regressietesten?

Regressietesten is een type testen dat gericht is op het bevestigen dat wijzigingen in de code de bestaande functionaliteit niet hebben aangetast. De term „regressie” betekent terugkeer naar een slechtere toestand — wanneer een functie die in de vorige versie werkte, stopt met werken in de nieuwe. Regressietests worden meerdere keren uitgevoerd in elke ontwikkelcyclus, wat ze onderscheidt van tests voor nieuwe functionaliteit die eenmalig worden geschreven.

De noodzaak van regressietesten vloeit voort uit het effect van cascaderende wijzigingen: het oplossen van een bug in één module kan het probleem verhelpen, maar aangrenzende functionaliteit die ervan afhankelijk was, breken. Een wijziging van een SQL-query in de gebruikersrepository kan bijvoorbeeld de aanmelding versnellen, maar de gegevensexport die dezelfde query gebruikte, breken. Een regressietest op de gegevensexport zal deze schending vóór de release detecteren.

Volgens het CISQ 2023-rapport zijn de kosten voor het oplossen van een regressiedefect dat in productie is ontdekt, 15 keer hoger dan in de fase van een geautomatiseerde regressierun. Bedrijven die investeren in geautomatiseerde regressietesten, verminderen het aandeel regressiedefecten in releases van 25% naar 5% binnen een jaar na implementatie, volgens het Capgemini World Quality Report.

Soorten regressietesten

Er zijn verschillende benaderingen van regressietesten, die verschillen in omvang en selectiecriteria van tests. De keuze van de benadering hangt af van de projectomvang, frequentie van wijzigingen en beschikbare tijd in de CI-pijplijn. Hieronder worden de belangrijkste soorten regressietesten met hun kenmerken gepresenteerd.

Volledige regressietesten

Volledige regressierun voert alle geautomatiseerde tests van het project zonder uitzondering uit. Deze benadering biedt maximaal vertrouwen, maar vereist aanzienlijke rekenkracht en tijd. Een volledige run wordt uitgevoerd vóór grote releases — eens per 2–4 weken. Voor een applicatie met 5000 tests duurt een volledige run 2 tot 6 uur, afhankelijk van de infrastructuur.

Selectieve regressietesten

De selectieve benadering start alleen tests die verband houden met gewijzigde modules. Om de verwantschap te bepalen, wordt afhankelijkheidsanalyse op codeniveau gebruikt: als de klasse UserRepository is gewijzigd, worden tests gestart die direct of transitief afhankelijk zijn van UserRepository. Tools zoals Jacoco, Android Test Coverage en Xcode Code Coverage bieden dekkingskaarten voor nauwkeurige selectie. Een selectieve run wordt uitgevoerd bij elke pull request en duurt 5–15 minuten.

Risicogebaseerde regressie

Risicogebaseerde regressie rangschikt tests op basis van de kritikaliteit van functionaliteit en de kans op breken. Kritieke functies — betaling, autorisatie, synchronisatie — worden getest bij elke codewijziging. Ondersteunende functies — het scherm „Over de app”, animaties — worden alleen vóór de release getest. De rangschikking wordt elk kwartaal herzien op basis van gegevens over productie-incidenten.

Hoe regressietesten verschillen van hertesten

Vaak worden de begrippen regressietesten en hertesten verward, hoewel het verschillende processen zijn. Hertesten is het opnieuw uitvoeren van een specifieke test die eerder was mislukt, na het oplossen van het defect. Het doel van hertesten is om te bevestigen dat de oplossing werkt: de bug wordt niet meer gereproduceerd. Hertesten wordt eenmalig uitgevoerd, direct na de fix en bevestiging van de fix door de ontwikkelaar.

Regressietesten is het uitvoeren van tests op bestaande functionaliteit die NIET is gewijzigd. Het doel is om te bevestigen dat het oplossen van één defect geen nieuw defect elders heeft gecreëerd. Regressietests worden meerdere keren uitgevoerd in elke ontwikkelcyclus, ongeacht welke specifieke bugs zijn opgelost. Het belangrijkste verschil: hertesten controleert de fix zelf, regressie controleert de gevolgen van de fix.

In de CI/CD-pijplijn worden beide processen sequentieel uitgevoerd. Na het mergen van een pull request wordt een hertest van de specifieke bug gestart, gevolgd door een volledige of selectieve regressierun. Volgens SmartBear (2022) verkort het scheiden van deze processen de diagnosticeertijd van mislukte CI-runs met 30%, omdat het team direct ziet welk deel van de defecten verband houdt met regressie en welk deel met niet-werkende fixes.

Automatisering van regressietesten

Automatisering van regressietesten is een kritische succesfactor voor moderne mobiele projecten. Handmatige regressietesten zijn niet schaalbaar: bij een set van 200 tests kost één run 2–3 werkdagen van een QA-ingenieur, wat dagelijkse runs onmogelijk maakt. Geautomatiseerde regressietests worden in 10–60 minuten uitgevoerd zonder menselijke tussenkomst, waardoor ze bij elke commit of pull request kunnen worden gestart.

• Eenheidstests — de basis van de regressieset (70%). Worden in seconden uitgevoerd, vereisen geen emulator, geven precies de gebroken klasse aan.
• Integratietests — het tweede niveau (20%). Controleren de netwerklaag, database en systeemdiensten met gecontroleerde afhankelijkheden.
• UI- en E2E-tests — de top van de piramide (10%). Dekken kritieke gebruikersscenario's: registratie, betaling, synchronisatie.

Om de regressieset actueel te houden, wordt testanalytics gebruikt: tools zoals Allure, ReportPortal en Xray volgen de slagingspercentages, duur en stabiliteit van elke test. Tests waarvan de stabiliteit onder 90% zakt (vaak breken door wijzigingen in vereisten), worden gemarkeerd als legacy en ter heroverweging naar de eigenaar gestuurd.

Voorbeeld van het configureren van een regressietest

Laten we het configureren van een geautomatiseerde regressietest op Android bekijken met behulp van de bibliotheek JUnit 5 en Espresso. Het voorbeeld demonstreert selectieve regressie — de test controleert of na refactoring van de gebruikersrepository het profielscherm niet is gebroken. Voor iOS wordt XCTest gebruikt met vergelijkbare logica — een herhaalde test op het belangrijkste scenario.

Android: regressietest van het profiel

De test gebruikt MockWebServer voor serveremulatie en controleert het volledige pad: het laden van gebruikersgegevens, weergave op het profielscherm en foutafhandeling wanneer de server niet beschikbaar is. Dergelijke tests worden opgenomen in de regressieset en uitgevoerd bij elke wijziging in module-profile.

@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("Laadfout").assertIsDisplayed()
    }
}

iOS: regressietest met XCTest

Voor iOS gebruikt de regressietest XCTestExpectation voor asynchrone controle van de UI-update na het ontvangen van gegevens van de API. De test emuleert een netwerkrespons en controleert of de UI-elementen correct zijn bijgewerkt.

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)
    }
}

Strategie voor het opbouwen van een regressieset

Het opbouwen van een effectieve regressieset is een iteratief proces op basis van gegevens over defecten en codewijzigingen. De primaire strategie is om alle bestaande tests in de regressieset op te nemen en vóór elke release een volledige run uit te voeren. Naarmate de testbasis groeit (boven de 2000 tests), wordt een volledige run te lang en is een selectieve benadering vereist.

De tweede fase — implementatie van tools voor afhankelijkheidsanalyse: Jacoco voor Android, Xcode Test Plan voor iOS. Deze tools bouwen een „test — klasse — methode”-kaart en maken het mogelijk te bepalen welke tests door een specifieke wijziging worden beïnvloed. Een selectieve run op basis van dekkingsanalyse verkort de uitvoeringstijd met 60–80% met behoud van 95% effectiviteit van regressiedetectie, volgens Spotify Engineering (2022).

De derde fase — continue monitoring en optimalisatie. Tests die 6 maanden niet zijn mislukt, worden verplaatst naar een lage-prioriteitsset. Tests die vaker dan één keer per maand mislukken, zijn kandidaten voor heroverweging: of ze vangen echte problemen (vereisen een fix), of ze zijn te broos (vereisen stabilisatie). Een kwartaalherziening van de regressieset is een standaardpraktijk om de effectiviteit en uitvoeringssnelheid te behouden.