Je past iets aan in je software, en opeens werkt er iets anders niet meer. Precies dat wil een software regression test voorkomen. Bij een regressietest voer je bestaande tests opnieuw uit na een wijziging, om te controleren of de software nog steeds doet wat hij moet doen. Het is geen nieuwe test, maar een herhaling van eerdere tests, gericht op alles wat al eerder werkte.
Wat is een software regression test precies?
Een regressietest is een verzameling testcases die je uitvoert nadat je code hebt gewijzigd. Denk aan een bugfix, een nieuwe functie of een update. De tests controleren of de bestaande werking intact is gebleven. Het woord “regressie” verwijst naar achteruitgang: je wil weten of de software is teruggegaan in kwaliteit door de verandering.
Het gaat bij een regressietest om zowel functionele tests (werkt de functie nog?) als niet-functionele tests (is de prestatie nog goed?). Je test dus niet alleen of nieuwe code klopt, maar ook of oude code niet is aangetast.
Waarom is dit anders dan een gewone test?
Een gewone test controleer je vaak maar één keer, om te bevestigen dat iets nieuw werkt. Een regressietest gebruik je opnieuw, steeds als er iets verandert in de software. Het verschil zit in het doel en het moment: een regressietest kijk je achteruit, naar wat al bestond. Een nieuwe test kijkt vooruit, naar wat er net is gebouwd.
Stel dat een ontwikkelaar een bug oplost in het inlogscherm. De bugfix zelf wordt getest. Maar met een regressietest controleer je ook of het uitloggen, het wachtwoord vergeten en het aanmaken van een account nog steeds werken. Je beschermt de functies die je niet hebt aangeraakt.
Wanneer voer je een regressietest uit?
Een regressietest hoort bij elke situatie waarin code verandert. De meest voorkomende momenten zijn:
- Na het oplossen van een bug
- Na het toevoegen van een nieuwe functie
- Na een software-update of patch
- Voor een nieuwe release of versie
- Na het aanpassen van configuraties of afhankelijkheden
Hoe vaker je software verandert, hoe vaker je regressietests nodig hebt. Bij teams die werken met continue levering van software zijn regressietests vrijwel dagelijkse kost.
Welke aanpak kies je voor regressietesten?
Je hoeft niet altijd alle tests opnieuw uit te voeren. Er zijn drie gangbare aanpakken:
- Volledige regressietest: je draait alle testcases opnieuw. Dit is grondig, maar kost de meeste tijd. Geschikt voor grote releases.
- Selectieve regressietest: je kiest alleen de tests die relevant zijn voor de aanpassing. Je beperkt de scope op basis van wat er is veranderd.
- Prioriteitsgebaseerde regressietest: je begint met de tests voor de meest gebruikte of kritieke functies. Handige aanpak als tijd schaars is.
Welke aanpak je kiest, hangt af van de grootte van de wijziging, de beschikbare tijd en het risico dat je accepteert. Bij kleine fixes is een selectieve aanpak vaak genoeg. Bij grote updates is een volledige regressietest verstandiger.
Handmatig of automatisch testen?
Regressietests kun je handmatig uitvoeren, maar dat is tijdrovend. Zeker als je veel testcases hebt of frequent aanpassingen maakt. Geautomatiseerde regressietests lossen dat probleem op: je schrijft de tests één keer en laat ze automatisch draaien bij elke wijziging.
Automatisering is zinvol als je een stabiele set testcases hebt die je keer op keer hergebruikt. Het kost vooraf meer tijd om de tests te schrijven, maar daarna verloopt het testen veel sneller. In omgevingen met continue integratie worden geautomatiseerde regressietests vaak automatisch gestart zodra nieuwe code wordt ingediend.
Handmatig testen blijft zinvol voor nieuwe of wisselende testscenario’s, of wanneer de kosten van automatisering niet opwegen tegen de voordelen.
Zo bouw je een goede regressietest op
- Breng de kernfuncties van je software in kaart. Dit zijn je verplichte testcases.
- Voeg testcases toe voor bugs die eerder zijn opgelost, zodat ze niet terugkomen.
- Kies voor automatisering bij tests die je steeds herhaalt.
- Pas je testset aan als de software structureel verandert.
- Voer de regressietest uit in een omgeving die lijkt op de productieomgeving.
- Registreer de resultaten en zorg dat fouten snel opvallen.
Regressietesten als vast onderdeel van je proces
Een software regression test is geen losstaande activiteit, maar een vast onderdeel van verantwoord software-ontwikkeling. Hoe groter en ouder een systeem wordt, hoe meer functies je moet beschermen bij elke nieuwe wijziging. Door regressietests vroeg in je werkwijze op te nemen, voorkom je dat kleine aanpassingen grote problemen veroorzaken. Dat spaart tijd, frustratie en reputatieschade.
Veelgestelde vragen
Wat is het verschil tussen een regressietest en een acceptatietest?
Een regressietest controleert of bestaande functies nog werken na een wijziging. Een acceptatietest controleert of nieuwe functionaliteit voldoet aan de eisen van de opdrachtgever of gebruiker. De regressietest kijkt achteruit, de acceptatietest kijkt vooruit naar wat nieuw is gebouwd.
Hoe vaak moet je een regressietest uitvoeren?
Je voert een regressietest uit na elke betekenisvolle wijziging in de code. Bij teams die dagelijks aanpassingen maken, hoort een regressietest dan ook dagelijks bij het proces. Bij minder frequente releases kan het minder vaak zijn, maar altijd vóór een nieuwe versie naar productie gaat.
Kan een regressietest garanderen dat er geen bugs zijn?
Nee. Een regressietest verkleint de kans op problemen, maar geeft geen volledige garantie. Je test alleen de scenario’s die je hebt bedacht en opgenomen in je testset. Onverwachte situaties of combinaties kunnen toch tot fouten leiden.
Welke functies neem je op in een regressietest?
In een regressietest neem je de kernfuncties op die gebruikers het meest gebruiken, functies die in het verleden problemen gaven, en alles wat direct geraakt kan worden door de huidige wijziging. Hoe kritischer een functie, hoe meer reden om hem altijd mee te nemen in de test.
