Regressietesten: waarom eigenlijk

Regressietesten moet, dat roepen velen en je vindt het ook overal en nergens terug als statement. Hoe langer ik er over nadenk, hoe meer ik me afvraag of dat eigenlijk wel zo is. Waarom moet er eigenlijk een regressietest zijn? Om antwoord te krijgen op die vraag ben ik op zoek gegaan naar de argumenten die worden aangedragen waarom een regressietest (al dan niet geautomatiseerd) nodig is.

Veruit het meest gebruikte argument is: ´wij doen scrum, dus dan kan het niet anders. We kunnen niet elke 2 weken alles testen, dus moet er een geautomatiseerde regressietest zijn´.

Een ander veelgebruikt argument is: ´wij willen zeker weten dat bij de introductie van nieuwe features er geen bestaande functies stuk zijn gegaan´

Een ander argument is: ´dat doen we altijd´, of ´omdat het moet van manager X of Y´ of ´het staat in onze teststrategie´.

Dan is er ook nog: ´onze keten is zo complex, een wijziging in systeem A kan onbekende gevolgen hebben in systeem B of F of X´

Dit zijn echter allemaal argumenten die geen antwoord geven op het waarom. Waarom wil je nu eigenlijk precies een regressietest. Een regressietest is een middel dat een doel (risico) afdekt. Welk doel of risico is dat dan en is een regressietest wel het juiste middel voor dat doel of risico.

Daarom ben ik op zoek gegaan naar de echte doelen en risico´s.

Wat ben ik daarbij zoal tegengekomen?

We werken Agile en kunnen niet voor iedere release alles testen. Dit is echter geen argument waarom je een regressietest hebt, want je gaat hierbij uit van het gegeven dat je elke release/sprint alles wilt testen. De vraag blijft dan nog steeds: waarom wil je dat dan?
Testers willen niet steeds dezelfde testen uitvoeren, dus hebben we de regressietest geautomatiseerd. Dit is geen argument om een regressietest te hebben, slecht een argument om hem niet steeds handmatig uit te hoeven voeren.
We willen zekerheid dat de meest gebruikte functies en flows in ons systeem altijd goed werken. De vervolgvraag is dan opnieuw: waarom en waarover wil je zekerheid? In die situaties waarop hier een antwoord voorhanden was, blijft de vraag of een regressietest het juiste middel is om die zekerheid te geven. Hierover later meer.
Onze keten is enorm complex en wijzigingen kunnen overal onbedoelde problemen veroorzaken. Dit is natuurlijk een groot probleem, het geeft een situatie weer waarin er totale chaos is ontstaan en niemand meer overzicht heeft over de keten van systemen en er blijkbaar ook niet wordt samengewerkt. Dit is echter nog steeds niet een argument waarom je een regressietest zou willen doen. De echte problemen worden daarmee niet aangepakt, slechts verhult in een heel duur regressie jasje.
In de situaties waarop de antwoorden ´dat doen we altijd´, ´moet van de manager´ en ´staat in de strategie´ waren, was er niemand die een verder achterliggend doel of risico kon noemen. Deze testers, coördinatoren en managers hadden zich blijkbaar nog nooit afgevraagd waarom ze doen wat ze doen.

Wat is eigenlijk een ´regressietest´?

Veel gebruikte definitie: met regressietesten wordt gecontroleerd of de niet aangepaste onderdelen van een applicatie nog steeds juist werken.

Hoe wordt dit in veel gevallen ingevuld?

De regressie testgevallen noteren we op enige wijze
We voeren die testgevallen uit naast de testen van de nieuwe/gewijzigde functies
Het aanvullen van de regressietest met de testgevallen van de nieuwe/gewijzigde functies

Wat betekent dit in de praktijk?

We voeren telkens opnieuw de testen uit die we al eerder hadden uitgevoerd
De regressietest wordt steeds groter
Het onderhoud op de regressietest wordt steeds groter

In bovenstaande werkwijze schuilt echter een groot probleem:

Hoe zinvol is het om steeds dezelfde testen opnieuw uit te voeren. Het antwoord daarop is simpel: dat is totaal niet zinvol. De kans om nieuwe problemen te ontdekken met testen die je eerder al hebt uitgevoerd is zo goed als nul. Daarmee is gelijk de waarde van die test bepaald, namelijk NUL. Verderop meer hierover.

De eerste vraag die je zou moeten stellen, als je toch al een regressietest hebt, is: hoe vaak vind ik nu precies problemen met die regressietest. Als het antwoord is: ´eigenlijk gaat het altijd goed´, dan heb je direct het antwoord op het nut van die regressietest. Als je echter wel veel issues vindt met het draaien van steeds dezelfde testen, dan heb je een heel ander en veel groter probleem. In die situatie heb je waarschijnlijk te maken met dubieuze kwaliteit code, niet zo goede ontwikkelaars of onder grote tijdsdruk ontstane software.

Is een regressietest dan altijd nutteloos?

Er zijn eigenlijk maar 3 situaties waarin een regressietest niet nutteloos is, maar zelfs dan alleen als je er op de juiste manier mee omgaat.

Situatie 1: je software is zo bedrijf kritisch dat het niet juist werken ervan een onaanvaardbaar groot risico betekent voor het bedrijf. Hierbij moet dan wel precies duidelijk zijn wat dat risico dan is en voor welke delen van die software dat risico dan geldig is. Op die wijze kun je de regressietest beperken tot een absoluut minimum.

Wees hierin als tester zeer kritisch, het maken en onderhouden van een regressietest is kostbaar en gaat ten koste van de tijd die je hebt voor het vinden van nieuwe bugs.

Situatie 2: je ontwikkelaars zijn onervaren en maken regelmatig bestaande functies stuk. Een regressietest kan dan een middel zijn om sneller van je fouten te leren.

Als dit de situatie is, dan kan een tijdelijke regressietest een goed middel zijn om het team hierbij te helpen. Zorg ervoor dat als het doel bereikt is, je de regressietest ook werkelijk weggooit.

Situatie 3: je team staat onder tijdsdruk waardoor er veel fouten worden gemaakt. Een regressietest kan een middel zijn om dit aan te tonen. Waak er wel voor dat de uitkomsten dan ook worden gebruikt om bewust te worden hiervan en niet als middel om het team te beoordelen.

Ook voor deze situatie geldt dat het middel zo snel mogelijk weer moet worden afgebouwd.

Hoe ziet een goede regressietest er dan uit als deze echt nodig is?

In de bovenstaande situaties, is het zaak om je regressietest op een slimme manier op te zetten (en bij voorkeur dan ook geautomatiseerd):

Alleen die delen die ook echt bedrijf kritisch zijn (delen die bij niet juist functioneren leiden tot situaties die niet- of niet eenvoudig herstelbaar zijn of tot grote onherstelbare schade leiden (financieel, wettelijk of imago))
Maak de testen zodanig dat ze niet elke keer met precies dezelfde data worden uitgevoerd. Door te variëren met testdata wordt de kans groter op het vinden van nieuwe bugs en daarmee wordt de test meer waardevol.
Evalueer continue of de testgevallen die je gebruikt, nog steeds zinvol zijn.

Conclusie:

De meeste regressietesten die we maken en uitvoeren zijn overbodig en overcompleet. In slechts een paar situaties is de regressietest, mits op de juiste wijze ingevuld, het juiste middel om een bepaald risico af te dekken.

Dus als zeker is dat een regressietest gerechtvaardigd is zorg dan dat de test zo klein mogelijk is, wees elke keer kritisch of er wellicht testcases weg kunnen in plaats van er steeds automatisch meer aan toe te voegen, en zorg tenslotte voor slimme testdata zodat er kans is dat de test van meer waarde is.

Ik wil dan ook alle testers oproepen om kritisch en sceptisch te zijn bij het ontwikkelen van regressietesten.

Naar het overzicht