Moderne software verandert voortdurend. Vooral wanneer er in een Agile-omgeving wordt gewerkt, waar releases zeer vaak plaatsvinden, soms zelfs via continue oplevering. Er worden voortdurend nieuwe functies toegevoegd, bestaande functies gewijzigd en softwarefouten opgelost. En dat is natuurlijk een goede zaak.
Maar tegelijkertijd is het risico dat bestaande, goed werkende functionaliteiten worden verbroken relatief groot. Daarom hebben we regressietesten nodig. Kort gezegd is regressietesten een techniek die valideert dat nieuwe wijzigingen in de code geen nieuwe bugs hebben geïntroduceerd.
Hieronder bespreek ik regressietesten, een cruciale praktijk voor kwaliteitsborging, uitgebreider.
Wat is regressietesten?
Regressietesten is een belangrijk onderdeel van de levenscyclus van softwareontwikkeling. Het is een type test dat wordt uitgevoerd om ervoor te zorgen dat wijzigingen in de code geen invloed hebben gehad op bestaande functionaliteiten en dat wat vóór deze wijzigingen werkte, nog steeds werkt. Problemen die tijdens dit proces worden gevonden, worden beschouwd als regressiefouten en moeten met hoge prioriteit worden behandeld.
Regressietesten kunnen zowel handmatig als via geautomatiseerde tests worden uitgevoerd. Het automatiseren van de regressietestsuite is een goed idee, vooral bij het werken met grote applicaties, waarbij het volledige regressieproces zeer tijdrovend kan zijn.
Waarom zijn regressietesten belangrijk bij softwareontwikkeling?
Wanneer er nieuwe code aan de codebasis wordt toegevoegd, of het nu om een foutoplossing of nieuwe functionaliteit gaat, kan dit invloed hebben op reeds werkende code doordat nieuwe defecten worden geïntroduceerd of doordat niet-functionele aspecten van de applicatie, zoals prestaties of bruikbaarheid, worden beïnvloed.
Dit kan leiden tot ongemak voor de eindgebruiker, die waarschijnlijk niet erg blij zal zijn dat iets wat vroeger werkte, niet meer werkt. Dit kan op zijn beurt leiden tot omzetverlies en een grote impact hebben op de reputatie van het bedrijf.
Regressietesten helpen deze bugs vroegtijdig op te sporen en dragen eraan bij dat er een oplossing beschikbaar is voordat de software naar productie wordt gebracht. Dit betekent dat klanten een stabielere versie van de applicatie te zien krijgen, zonder dat dit gevolgen heeft voor de oude functionaliteiten die ze al gebruikten.
Selectie van testgevallen
Het eerste wat testers moeten doen voordat ze met de regressietest beginnen, is bepalen welke regressietestgevallen moeten worden uitgevoerd. Er zijn twee belangrijke methoden voor de selectie van testgevallen: reactief en proactief.
Reactief
Bij een reactieve selectie van testgevallen onderneemt het kwaliteitsborgingsteam actie na de wijziging. Dit betekent dat de uit te voeren testgevallen worden geselecteerd nadat het ontwikkelingsteam wijzigingen in de code heeft aangebracht.
Proactief
Bij de proactieve aanpak anticiperen testers op mogelijke wijzigingen voordat de ontwikkelingsaanpassingen worden doorgevoerd en stellen ze het testplan dienovereenkomstig op. De keuze tussen deze twee methoden hangt af van bepaalde factoren, waaronder kosten, complexiteit, dekking en tijdsbeperkingen.
Prioritering van testgevallen
Het prioriteren van testgevallen is waarschijnlijk een van de belangrijkste stappen bij het opstellen van een regressieplan. Het helpt om de tijd effectief te beheren en verbetert de foutdetectiegraad. Het eerste wat moet gebeuren, is inzicht krijgen in welke gebieden het meest zijn beïnvloed door recente wijzigingen en bepalen hoeveel tijd het team heeft om de regressietesten uit te voeren. Zoals een van de bekende testprincipes stelt: “uitputtend testen is onmogelijk”, wat betekent dat we niet alle bestaande testscenario’s en randgevallen kunnen afdekken, maar wel kunnen streven naar de best mogelijke testdekking.
Met dit in gedachten moeten testers een risicoanalyse uitvoeren: bepalen welke gebieden het belangrijkst zijn om te testen en welke waarschijnlijk de meeste problemen zullen veroorzaken. Wat testprincipes betreft, moet je onthouden dat defecten zich vaak clusteren. Dat wil zeggen dat een gebied met problemen waarschijnlijk de meeste defecten aan het licht zal brengen. Bij regressietesten zijn dit de gebieden die zijn gewijzigd.
Een ander aspect om rekening mee te houden is of we testautomatisering gebruiken. De geautomatiseerde testuitvoering kan onafhankelijk worden uitgevoerd, waardoor testers zich meer kunnen richten op ervaringsgerichte tests, zoals verkennende en ad-hoc-tests, en op onderdelen die niet kunnen worden geautomatiseerd, zoals controleren of de gebruikerservaring op geen enkele manier is verslechterd.
Naarmate de software wordt gewijzigd, is het ook belangrijk om bestaande testgevallen bij te werken zodat ze de nieuwe wijzigingen weerspiegelen, of verouderde testgevallen overeenkomstig te markeren, zodat ze niet per ongeluk worden uitgevoerd.
Technieken & hulpmiddelen voor effectieve regressietesten

| Techniek waarbij alles opnieuw wordt getest | Selectieve techniek | Prioriteringstechniek |
|---|---|---|
| Deze techniek staat ook bekend als volledige regressietest en is de meest grondige regressietesttechniek. Hierbij wordt elke functie binnen de software opnieuw getest na elke wijziging. Het doel is 100% testdekking. Daarvoor moeten alle bestaande tests opnieuw worden uitgevoerd en moeten nieuwe testgevallen worden uitgevoerd. Deze techniek is vooral geschikt voor geautomatiseerde regressietests als het merendeel van de testsuite is geautomatiseerd. Het is de veiligste techniek, maar niet erg efficiënt wanneer deze handmatig wordt uitgevoerd, omdat het veel tijd kan kosten om de volledige regressietestsuite te doorlopen. | Dit is een gedeeltelijke regressietesttechniek, waarbij het team alleen de functies opnieuw test die zijn beïnvloed door de gewijzigde delen van de code. Dit houdt nauw verband met de selectie van regressietests. Er wordt een regressietestsuite samengesteld door bestaande en nieuwe tests te selecteren die betrekking hebben op de gebieden waaraan oplossingen en verbeteringen zijn toegevoegd. Deze testgevallen worden ook geprioriteerd op basis van het risico en het belang van de functionaliteiten. | Dit is een testbenadering waarbij de functies worden getest op basis van hun belang en invloed op de algehele functionaliteit van de software. Het testteam beoordeelt de kernfuncties van de software en zorgt ervoor dat deze grondig worden getest. Het idee achter deze techniek is ervoor te zorgen dat de belangrijkste onderdelen van de applicatie niet zijn aangetast. Toch is dit geen erg efficiënte techniek, omdat deze zich niet richt op gebieden die zijn gewijzigd en veel hertests vereist van onderdelen die sinds hun vorige test waarschijnlijk niet zijn veranderd. |
De rol van automatisering bij regressietests
Bij testautomatisering is het belangrijk om rekening te houden met de piramide van testautomatisering. Deze stelt dat het grootste deel van de tests uit unittests moet bestaan, omdat deze sneller kunnen worden uitgevoerd en daardoor defecten sneller kunnen identificeren. Daarnaast zijn er integratietests (of API-tests), die minder talrijk zijn maar nog steeds een groot aantal uit te voeren tests vertegenwoordigen.
Op de bovenste laag duren UI-tests van begin tot eind het langst om uit te voeren. Deze tests moeten daarom minder talrijk zijn dan de tests op de andere niveaus.
Door geautomatiseerde testscripts te gebruiken, kan het volledige regressieproces worden geoptimaliseerd. Testgevallen worden sneller uitgevoerd en defecten worden snel geïdentificeerd, met zeer weinig menselijke tussenkomst. De geautomatiseerde tests kunnen telkens worden uitgevoerd wanneer er wijzigingen in de broncode worden aangebracht. Op basis van de testresultaten kunnen testers achterhalen welke gebieden sterker zijn beïnvloed en deze gebieden tijdens hun handmatige tests grondiger onderzoeken.
Verkennend testen is altijd een goede manier om automatisering aan te vullen, omdat het een type test is dat niet kan worden geautomatiseerd. Bovendien kan de ervaring van testers veel waarde toevoegen door minder gebruikelijke scenario's te identificeren.
Tools voor regressietests
Het ontwikkelingsteam beheert doorgaans de eerste twee lagen van de piramide. In dit gedeelte bespreken we daarom enkele van de populairste tools voor UI-automatisering die kunnen helpen bij het automatiseren van het testproces.
| Selenium | Appium | JMeter | Katalon |
|---|---|---|---|
| Een opensourcetool voor het automatiseren van browsers, die vaak wordt gebruikt voor testautomatisering van webapplicaties. De tool is beschikbaar in meerdere programmeertalen, waaronder Java, Python, JavaScript en C#, en werkt op alle besturingssystemen en met gangbare browsers. De testers die de scripts maken, moeten echter wel over programmeerkennis beschikken. | Appium is het mobiele equivalent van Selenium: een testframework dat is ontworpen voor het testen van mobiele apps. De tool is ook beschikbaar in verschillende programmeertalen en werkt zowel op Android als op iOS. | JMeter is eveneens een opensourcetool en kan worden gebruikt voor functioneel testen, maar is vooral krachtig vanwege de mogelijkheden voor prestatietests. Het is een uitstekende tool wanneer u belasting- of stresstests op uw applicatie moet uitvoeren en de resultaten wilt vergelijken met die van vóór de codewijzigingen, om te zien of de prestaties op enige manier zijn beïnvloed. | Katalon is een tool voor het testen van software in web-, mobiele, API- en desktopapplicaties. De tool biedt ook functionaliteit voor opnemen en afspelen, waardoor deze goed werkt in teams waarin testers niet noodzakelijkerwijs programmeurs zijn |
De lijst kan natuurlijk worden uitgebreid, omdat er veel geautomatiseerde testtools op de markt beschikbaar zijn. Welke tool u kiest, hangt af van de specifieke behoeften van het project en het team.
Uitdagingen bij de implementatie
Hoewel het regressietestproces een integraal onderdeel is van de ontwikkelingscyclus, brengt het wel uitdagingen met zich mee.
- Tijdsbeperkingen: Tijd is waarschijnlijk de meest voorkomende uitdaging bij regressietesten. Omdat de regressietestsuite steeds groter wordt naarmate er nieuwe modules aan de code worden toegevoegd, kan dit veel tijd in beslag nemen, waar het team niet altijd over beschikt. Meer tijd besteden aan regressietesten kan ook de kosten verhogen.
- Onderhoud: Naarmate de bestaande code wordt gewijzigd om nieuwe functionaliteiten en verbeteringen toe te voegen, moeten ook de testgevallen worden onderhouden. Dit geldt voor handmatige en geautomatiseerde tests, omdat alle bestaande testscenario's de nieuwe vereisten moeten weerspiegelen.
- Prioritering: Een van de belangrijkste stappen van regressietesten. Het team moet ervoor zorgen dat het, rekening houdend met de beschikbare tijd voor het uitvoeren van regressietests, de juiste testgevallen en scripts selecteert om de testdekking te maximaliseren en tegelijkertijd de omvang van de testsuite te minimaliseren.
De impact van efficiënte regressietesten op productkwaliteit
Ondanks de uitdagingen heeft regressietesten een grote impact op de softwarekwaliteit wanneer dit goed wordt uitgevoerd.
Ten eerste zorgt het team er met regressietesten voor dat er geen nieuwe bugs worden geïntroduceerd nadat nieuwe functionaliteiten aan de applicatie zijn toegevoegd.
Dit heeft een kettingreactie op de codekwaliteit en de algehele kwaliteit van het systeem dat wordt getest.
Minder bugs in productie betekenen ook een grotere klanttevredenheid en een betere klantervaring.
Belangrijkste punten
Regressietesten vormen een integraal onderdeel van de teststrategie van elk succesvol ontwikkelproces. Ze helpen ervoor te zorgen dat nieuw toegevoegde functies en oplossingen geen invloed hebben op de bestaande werkende code en dat het systeem voldoet aan de normen voor vrijgave in productie.
Met de juiste prioritering van testgevallen en behulp van automatiseringstools kan het regressieproces een zeer efficiënte manier zijn om het risico te beperken dat iets wat eerder werkte, defect raakt. Dit helpt de eindgebruiker op zijn beurt aan een goede gebruikerservaring.
Lees meer over regressietesten en alles wat met testen te maken heeft en abonneer je op de QA Lead-nieuwsbrief!
