Vrijdagmiddag, 16:00. De release staat gepland voor 17:00. En dan vraagt iemand: “Hebben we de regressietests al gedraaid?”
Stilte.
“Die duren 8 uur,” zegt de tester. “We kunnen maandag wel…”
En dan weet je: dit had anders gekund. Maar wanneer precies? En hoe?
Dit scenario ken je waarschijnlijk. Valkuilen bij regressietesten sluipen er langzaam in: een regressiesuite die zo groot is geworden dat niemand hem meer durft te draaien.
Tests die falen maar waar niemand naar kijkt. Functies die al jaren verwijderd zijn, maar waarvan de tests nog steeds draaien.
Herkenbaar? Dan zit je waarschijnlijk vast in een of meerdere van de vijf valkuilen die in dit artikel aan bod komen. En belangrijker: je leert hoe je eruit komt. Niet met theoretische adviezen, maar met concrete stappen die je deze week nog kunt zetten.
Wil je eerst weten wanneer en hoe vaak je regressietesten het beste inzet? Lees dan regressietesten: wanneer, hoe en hoe vaak doe je het goed?
Je suite groeit, maar krimpt nooit. Herken je dit?
Een van de meest voorkomende valkuilen bij regressietesten is dat suites alleen maar groeien, maar nooit krimpen.
Stel je Lisa voor, test lead bij een e-commerce bedrijf. Hun suite heeft 2.400 tests en een doorlooptijd van bijna 10 uur. “We durven niks te verwijderen,” zegt ze. “Want stel dat we net die ene test weghalen die een kritieke bug zou vangen?”
Dat klinkt logisch, toch? Maar hier zit de denkfout: meer tests betekent niet automatisch betere kwaliteit. Sterker nog, vaak is het tegenovergestelde waar. Dat is niet uitzonderlijk, trouwens. De meeste suites zijn precies zo gegroeid.
Waarom? Omdat een te grote suite drie problemen veroorzaakt die elkaar versterken.
Ten eerste draait niemand de suite meer. Als je testsuite 10 uur duurt, draai je hem niet bij elke commit. Misschien wekelijks, of erger: alleen voor releases. Dat betekent dat bugs dagen of zelfs weken onontdekt blijven.
Ten tweede worden falende tests genegeerd. Bij 2.400 tests falen er altijd wel een paar, en na een tijdje went het team aan die rode cijfers. “Ach, die faalt altijd,” hoor je dan. Tot er een echte bug tussen zit die niemand opmerkt omdat hij verdwijnt in de ruis.
Ten derde wordt onderhoud onmogelijk. Want wie houdt 2.400 tests bij? Tests verouderen langzaam: tests voor functies die niet meer bestaan, tests voor API versie 1 terwijl je al op versie 3 zit.
De oplossing: plan een opschoonsessie
Plan elk kwartaal een opschoonsessie waarin je tests verwijdert. Blokkeer een middag met je team, ga door de suite, en stel bij elke test de vraag: “Is dit nog relevant?”
Een test is niet meer relevant als de functie niet meer bestaat, als de test al 6 maanden niet meer gefaald heeft, of als er een betere test is die hetzelfde dekt.
Bij Lisa’s team? Ze gingen van 2.400 naar 800 tests, en de doorlooptijd daalde van 10 uur naar 2,5 uur. Weet je wat er toen gebeurde? Ze vonden meer bugs, niet minder. Omdat ze de suite nu wel bij elke merge draaiden.
Maar minder tests alleen is niet genoeg. Want welke tests houd je dan over? Dat is precies waar de volgende valkuil op de loer ligt.
Je admin panel heeft evenveel tests als je checkout. Dat klopt niet.
De tweede valkuil gaat over prioritering. Hier is een vraag die teams vaak te horen krijgen: “Als je maar een uur hebt om te testen, welke tests draai je dan?”
Meestal volgt er een ongemakkelijke stilte. De meeste teams behandelen al hun tests als even belangrijk. De login flow krijgt evenveel aandacht als de tooltip op een admin pagina die twee mensen per maand zien. Dat klinkt eerlijk, maar het is niet slim.
Stel je een team voor dat hun hele applicatie “gelijk” testte. Hun checkout flow, goed voor 80% van de omzet, had evenveel testdekking als hun “over ons” pagina. De bug die 40.000 euro kostte, zat precies in de checkout.
De oplossing: test naar risico
Je hoeft niet alles evenveel te testen. Risico is eigenlijk simpel: wat is de kans dat iets kapot gaat, vermenigvuldigd met de impact als het kapot is?
Een simpele matrix helpt hierbij:
| Vaak aangepast | Zelden aangepast | |
|---|---|---|
| Hoge business impact | P0: test intensief, bij elke commit | P1: test regelmatig |
| Lage business impact | P1: test regelmatig | P2: test oppervlakkig |
Je checkout flow? P0. Die tooltip? P2. Zodra je dit expliciet maakt, wordt je suite vanzelf efficiënter. Je stopt met testen wat er niet toe doet, en je gaat dieper testen wat er wel toe doet.
Maar goed, je weet nu wat je moet testen. De volgende vraag is: hoe test je het?
Elke sprint dezelfde 50 tests handmatig draaien. Tot het dat niet meer is.
Elke sprint dezelfde 50 tests handmatig draaien, sprint na sprint. Dat zien we vaker dan je denkt.
Het is begrijpelijk waarom teams dit doen: automatiseren kost tijd, het is technisch, en je moet het onderhouden. Handmatig testen kun je gewoon… doen.
Maar hier is de rekening: als een test 15 minuten duurt en je draait hem 100 keer per jaar, ben je 25 uur per jaar kwijt aan die ene test. Automatiseren kost misschien 2 uur. Die investering verdien je binnen een maand terug.
En handmatig testen is ook gewoon saai. Testers die elke sprint dezelfde 50 flows moeten aflopen, raken gedemotiveerd. Gedemotiveerde testers missen bugs, want hun aandacht verslapt.
De oplossing: automatiseer wat je vaak doet
De truc is niet om alles te automatiseren. Automatiseer alleen wat je vaak doet en wat stabiel is. Een goede vuistregel: als je een test meer dan drie keer draait, automatiseer hem.
Begin met de tests die je het vaakst doet: login flows, basale navigatie, checkout stappen. En laat je handmatige testers dan doen waar ze goed in zijn: nieuwe functies onderzoeken, edge cases ontdekken. Dat is waar menselijke creativiteit waarde toevoegt, niet bij het voor de honderdste keer checken of de login nog werkt.
Oke, dus je hebt geautomatiseerd wat je vaak doet. Maar hoe vaak draai je die tests? Want ook daar gaat het regelmatig mis.
8 uur wachten omdat iemand een button-kleur aanpaste
Een developer past de kleur van een button aan. Een CSS-wijziging, niks functioneels. Wat gebeurt er? De hele regressiesuite draait. 2.000 tests. 8 uur wachten. Voor een button-kleur.
Dit zien we bij teams die “safe” willen spelen. Dat klinkt verstandig, maar is het niet. Want wat gebeurt er in de praktijk? Developers gaan de pipeline vermijden. Ze bundelen changes om minder vaak te hoeven wachten, of ze pushen vrijdag om 17:00 en hopen dat het goed gaat. Geen van beide is wat je wilt.
De oplossing: test impact analysis
Koppel je tests aan de code die ze testen. Als dan alleen Button.jsx verandert, draai je alleen de tests die met buttons te maken hebben. Dit werkt het beste als je regressietesten goed hebt ingebed in je continuous integration pipeline.
Een simpele koppeling is al genoeg:
{
"components/Button.jsx": ["test-button-renders", "test-button-click"],
"services/checkout.js": ["test-checkout-flow", "test-payment-processing"]
}In plaats van 8 uur wachten voor elke change, wacht je 10 minuten voor kleine changes. De volledige suite draai je alleen wekelijks of voor releases.
Maar er is nog een valkuil die misschien wel de gevaarlijkste is. Wat er dan gebeurt? Niemand kijkt er meer naar.
Als 30% falen “normaal” wordt, heb je een probleem
De suite draait, 30% faalt. Iemand kijkt ernaar en zegt: “Ja, dat zijn bekende falende tests. Instabiele tests. Negeer maar.”
Na een tijdje kijkt niemand meer naar wat er faalt, want het zijn toch altijd dezelfde tests. En dan komt er een echte bug voorbij, eentje die ertoe doet. Maar niemand merkt het op, want hij verdwijnt in de ruis.
Stel je een team voor waar dit gebeurde: 40% van hun tests faalde “normaal”. Op een dag zat er een kritieke security bug tussen. Drie weken lang. Niemand had het door.
De oplossing: nultolerantie voor instabiele tests
Een test die faalt? Fix hem binnen 24 uur. Lukt dat niet, verwijder hem dan. Dat klinkt hard, maar het alternatief is erger: een suite waar niemand meer naar kijkt.
Wat ook helpt is eigenaarschap. Wijs elke testsuite toe aan een persoon. Als tests in jouw suite falen, ben jij verantwoordelijk voor de fix. Niet “het team.” Jij. Zodra mensen persoonlijk verantwoordelijk zijn, worden tests opeens wel onderhouden.
Wat je morgen anders kunt doen
Je hoeft niet alles tegelijk aan te pakken. Begin met een ding.
Misschien is dat die ene test voor de functie die vorig jaar verwijderd is. Weg ermee. Of die instabiele test die “soms” faalt. Vandaag: fix hem of verwijder hem. Geen “we kijken er later naar.”
Een andere goede eerste stap: label je top 10 tests als P0. Welke tests moeten altijd slagen? Welke dekken je meest kritieke flows? Markeer ze, en zorg dat die bij elke commit draaien.
Het zijn kleine stappen, maar ze vormen het begin van een testsuite die bugs vangt in plaats van ze te verbergen. Dat is uiteindelijk waar het om draait.
Soms is het fijn om even met iemand te sparren die dit van buitenaf ziet. Niet om een oplossing op te leggen, maar gewoon om samen te kijken waar de winst zit voor jouw situatie. We denken graag vrijblijvend met je mee.
