Skip to main content

Regressietesten is een van de belangrijkste testtypen in elk softwareontwikkelingsproject. Op zeer hoog niveau is het doel om te bevestigen dat nieuwe ontwikkelingen geen bugs of defecten hebben geïntroduceerd in eerder werkende onderdelen.

Door mijn ervaring met verschillende projecten in uiteenlopende bedrijfsdomeinen heb ik geleerd dat elk team zijn eigen processen heeft voor het uitvoeren van regressietesten van software. Toch zijn er enkele gemeenschappelijke punten die alle succesvolle testprojecten delen.

Deze handleiding geeft je de kennis om regressietesten volledig te beheersen. Je ontdekt het arsenaal aan krachtige tools voor regressietesten om het proces te stroomlijnen en een soepele ontwikkelworkflow te garanderen. Ik deel de lessen die ik onderweg heb geleerd.

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Wat zijn regressietesten in softwareontwikkeling?

Het ontstaan van nieuwe defecten en/of het opnieuw optreden van problemen is relatief normaal wanneer software wordt bijgewerkt, gewijzigd of opnieuw wordt gebruikt op een aangepast doelplatform. 

schermafbeelding van regressietesten in softwareontwikkeling

Om ervoor te zorgen dat deze defecten worden ontdekt voordat de software-updates naar productie worden uitgebracht, moet het QA-team zich richten op het tijdig vinden ervan - en daar komen regressietesten om de hoek kijken.

Regressietesten zijn een testtype waarbij wordt gecontroleerd of de functionaliteit van reeds bestaande functies van een softwareapplicatie nog werkt. Regressietesten worden na elke wijziging of update van de code uitgevoerd om te garanderen dat de bestaande functionaliteiten werken zoals bedoeld, zonder revisies of toevoegingen. Afhankelijk van de omvang van het project kunnen handmatige of geautomatiseerde regressietesten worden gebruikt.

Wanneer moet je regressietesten gebruiken?

Wanneer nieuwe functies of verbeteringen aan een bestaande codebasis of applicatie worden toegevoegd, zijn regressietesten noodzakelijk. Ze garanderen dat toegevoegde functies of updates aan een bestaande applicatie foutloos en zonder fouten functioneren. De kans op incompatibiliteitsproblemen in de code is groot, omdat ontwikkelaars en testers vaak moeite hebben om elke codestroom te traceren. Daarom stelt het uitvoeren van regressietests op hun software (of applicatie) hen in staat bugs eerder te vinden en software met minder risico's uit te brengen.

Wanneer een implementatie meer tijd in beslag neemt dan verwacht, kunnen regressietesten worden toegepast. In dit scenario moet de tester elke dag regressietests uitvoeren. Daarnaast verdient het bij wekelijkse releases de voorkeur om regressietesten na functionele tests uit te voeren.

Geautomatiseerde regressietesten

De regressietestbibliotheek groeit naarmate het team softwarefuncties toevoegt. De regressietestsuite kan na verloop van tijd zo groot worden dat het onmogelijk wordt om de tests handmatig uit te voeren binnen de beperkte Agile-sprintcycli.

Regressietesten lenen zich uitstekend voor testautomatisering, omdat ze herhaalbaar en terugkerend moeten zijn. Voor elke release kun je een grondige regressietest uitvoeren en je kunt slankere, snellere testsuites met feedback ontwikkelen om na codewijzigingen (hotfixes) op regressies te controleren. Ontdek tools voor softwaretesten die bijzonder effectief zijn voor regressietestscenario's.

Wanneer voer je regressietesten uit?

Regressietesten zijn noodzakelijk telkens wanneer nieuwe functies of verbeteringen aan een bestaande codebasis of applicatie worden toegevoegd. Ze garanderen dat toegevoegde functies of updates aan een bestaande applicatie foutloos en zonder fouten functioneren. De kans op incompatibiliteitsproblemen in de code is groot, omdat ontwikkelaars en testers vaak moeite hebben om elke codestroom te traceren. Daarom stelt het uitvoeren van regressietests op hun software (of applicatie) hen in staat bugs eerder te vinden en software met minder risico's uit te brengen.

Handmatige regressietesten moeten worden uitgevoerd als testautomatisering niet met het buildsysteem is geïntegreerd en/of geautomatiseerde testruns niet regelmatig zijn ingepland. Is het dan nodig om elke codewijziging terug te volgen? Nee, dat is niet het antwoord.

Regressietesten zijn alleen nodig wanneer een codewijziging invloed heeft op andere delen van het product. Om dit vast te stellen, moet worden onderzocht hoe de gewijzigde module samenwerkt met andere productmodules.

Meestal zijn ontwikkelaars die wijzigingen aanbrengen zich bewust van de mogelijke effecten op andere modules en het gedrag van het gehele product, en moeten zij indien nodig op passende wijze om regressietesten verzoeken.

Get regular tech leadership wisdom for delivering better software and systems.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form

Wie is verantwoordelijk voor regressietesten?

Nadat functioneel testen is voltooid, worden regressietesten uitgevoerd om te controleren of alle andere functionaliteiten werken. Dit is doorgaans de verantwoordelijkheid van het QA-team. Nieuwe testers die de functie nog niet eerder hebben getest, maar gedocumenteerde testgevallen kunnen uitvoeren, kunnen ook bij het regressieproces worden betrokken. In deze gevallen moeten de regressietestgevallen goed worden beschreven, zodat zelfs iemand die nieuw is in het team ze kan volgen. 

Ook testers die de functionele tests mogelijk nog niet eerder hebben uitgevoerd, maar wel veel ervaring hebben met de functies die moeten worden getest, hebben een goede kans om grote bugs te vinden, als die zijn geïntroduceerd.

Hoe weet je wanneer regressietesten zijn voltooid?

Je moet een delicate balans vinden tussen wat je qua tijd en middelen kunt behandelen als onderdeel van de regressietests en het risico dat het team kan dragen.

Hier zijn enkele zaken waarmee het testteam rekening kan houden bij het inschatten van risico's:

  • Als een functie intensief wordt gebruikt door de gebruikers van de software, moet deze prioriteit krijgen in het regressietestplan.
  • Technische onderdelen van het product die in het verleden stabiel zijn gebleken en waarvan bekend is dat ze goede testrapporten opleveren, brengen minder risico met zich mee. Daarom kunnen softwaretesters ervoor kiezen om deze niet op te nemen in de regressietests.
  • Het analyseren van eerder gemelde defecten door klanten of het interne QA-team kan helpen om zwakkere onderdelen van de app te identificeren waarop de regressie-inspanningen zich moeten richten.
  • Als bugs lange tijd open zijn gebleven zonder te worden opgelost, hebben ze weinig invloed op de workflows van gebruikers en hebben zij hiervoor workarounds gevonden.

Technieken voor regressietests

De belangrijkste technieken die worden gebruikt bij het uitvoeren van regressietests zijn: 

  • Volledige regressie, ook wel alles opnieuw testen genoemd
  • Selectie van regressietests
  • Prioritering van testgevallen

Volledige regressie

Bij deze methode worden regressietests uitgevoerd op alle actieve testsuites. Hoewel deze aanpak veel tijd en middelen vereist, is het de veiligste techniek om te garanderen dat alle defecten worden gevonden en opgelost, omdat deze de hoogste testdekking heeft.

Daarom zijn er specifieke situaties waarin de strategie van volledige regressietests beter werkt dan andere strategieën, bijvoorbeeld wanneer de applicatie wordt aangepast voor een nieuw platform of een nieuwe taal, of wanneer het besturingssysteem een belangrijke update krijgt.

Testselectie (of gedeeltelijke regressietests)

Bij deze techniek worden testgevallen uit de testsuite geselecteerd om opnieuw uit te voeren. De selectie van testgevallen is gebaseerd op de codewijzigingen in de module.

Prioritering van testgevallen 

Bij deze aanpak kun je testgevallen met de hoogste prioriteit voorrang geven in het regressietestproces. Dit zijn ook goede kandidaten voor geautomatiseerde tests. De tests moeten worden geprioriteerd op basis van hun foutpercentage, bedrijfsimpact en gebruikte functionaliteiten. 

Ook aan testgevallen die betrekking hebben op realistische scenario's en nieuwe functionaliteiten moet een hoge prioriteit worden gegeven.

Regressietests versus hertesten

In tegenstelling tot regressietests, waarbij testers controleren of de bestaande functionaliteit nog steeds werkt, bevestigt hertesten dat een bug is opgelost. Hertesten richt zich uitsluitend op mislukte testgevallen en controleert of de uitkomst van het testgeval is veranderd. 

Agile-regressietests

Wanneer je in een agile omgeving werkt, worden er elke sprint nieuwe functies geïntroduceerd. De regressietestsuite moet daarom altijd up-to-date worden gehouden om na de sprint de juiste werking van alle functies te garanderen. In Agile-omgevingen waarin code vaak wordt gewijzigd, kunnen efficiënte QA-automatiseringstools een uitkomst bieden om regressietests bij te houden. De regressiesuite moet voortdurend testgevallen toevoegen die overeenkomen met alle geteste en stabiele functies, en testgevallen die niet langer van toepassing zijn, moeten worden verwijderd.

Visuele regressietests

De regressietestaanpak wordt ook gebruikt bij visuele regressietests. Visuele regressietests controleren echter alleen de visuele elementen van de software. Met andere woorden: ze zorgen ervoor dat geen enkel onderdeel van de visuele interface van de software door codewijzigingen wordt aangetast.

Een visuele regressietest controleert wat de gebruiker zou zien nadat het systeem is gewijzigd, door momentopnamen die vóór en na de wijzigingen zijn gemaakt met elkaar te vergelijken. 

Unit-tests versus regressietests

Het doel van unit-tests is controleren of afzonderlijke code-eenheden onafhankelijk werken zoals verwacht. Ze worden uitgevoerd terwijl de code wordt ontwikkeld, eenheid voor eenheid, vroeg in de ontwikkelingscyclus. 

Regressietests worden daarentegen later in de ontwikkelingscyclus uitgevoerd, wanneer er code-updates of bugfixes zijn. Regressietests omvatten meestal de volledige applicatie of software.

Sanity-tests versus regressietests

Sanity-tests worden uitgevoerd om te beoordelen of de software na de toevoeging van een nieuwe module of functionaliteit werkt zoals bedoeld. Sanity-tests zijn een methode voor softwaretests waarmee de kwaliteit van een softwarerelease snel wordt beoordeeld om te bepalen of deze in aanmerking komt voor verder testen.

Sanitytesten beoordelen dus de stabiliteit van nieuw toegevoegde functies of codewijzigingen in de huidige build. Regressietesten verifiëren of alle gebieden die door functionaliteitswijzigingen of codewijzigingen zijn beïnvloed, stabiel zijn.

Belangrijkste punten 

De gebruikerservaring en de algehele productkwaliteit kunnen aanzienlijk worden verbeterd door regressietesten.

Regressietesten in Agile bieden ook verschillende technische en commerciële voordelen. Hoe meer uw bedrijf investeert in het plannen en uitvoeren van regressietesten, hoe meer controle u heeft over het budget, het proces en het beperken van fouten van uw product.

Als u meer wilt leren over onderwerpen op het gebied van kwaliteitsborging, abonneer u dan op de nieuwsbrief van QA Lead!