27 okt 2026 Risicogebaseerd testen: zo kies je een kleine regressieset die dekt wat ertoe doet

In het kort: Bij risicogebaseerd testen steek je je testtijd in de plekken waar een fout het meeste pijn doet. Voor regressietesten scoor je elk bedrijfsproces op de kans dat het breekt en op de schade als dat gebeurt. Daarna automatiseer je een kleine set die de grootste risico’s afdekt en elke nacht draait. De rest test je lichter en minder vaak.

Een regressieset die de hele nacht nodig heeft, voelt veilig. Maar juist grote sets verbergen vaak een probleem. Er vallen zoveel tests om zonder echte bug dat niemand de uitslag nog goed leest. Wat een release beschermt, is een set die bewaakt wat echt pijn doet als het stukgaat. Risicogebaseerd testen helpt je die dingen te vinden. Zo kies je een kleine regressieset waar je team op kan vertrouwen.

Wat is risicogebaseerd testen?

Risicogebaseerd testen is een manier om te bepalen wat je test, en hoe grondig, op basis van risico. Risico bestaat hier uit twee delen. Het eerste is de kans: hoe groot is de kans dat dit deel van het systeem breekt? Het tweede is de impact: hoe erg is het voor je klanten of je bedrijf als het breekt? Een onderdeel dat vaak verandert en met geld werkt, scoort op allebei hoog. Een instellingenpagina die bijna niemand gebruikt, scoort laag. Je test de onderdelen met een hoog risico eerst en het grondigst. De rest test je lichter of minder vaak. Het idee is niet nieuw. Testmethodes als TMap en de syllabus van ISTQB bouwen er allebei op. In het Engels heet het risk-based testing. Voor een regressieset levert het één heldere regel op. Elke test moet een echt risico bewaken, en de grootste risico’s krijgen de betrouwbaarste tests.

Bij regressietesten levert dit het meeste op. Een regressietest controleert of wat gisteren werkte, na een wijziging nog steeds werkt. Je draait hem steeds opnieuw, dus elke extra test kost bij elke run tijd. De basis staat in onze uitleg over de regressietest. Bij de keuze wat er in de set komt, helpt risico je verder.

Hoe scoor je het risico van een bedrijfsproces?

Geef elk bedrijfsproces een score van 1 tot 3 voor kans en voor impact, en vermenigvuldig die twee. Een bedrijfsproces is iets wat een gebruiker of systeem van begin tot eind doet, zoals een bestelling plaatsen of een factuur goedkeuren. Door processen te scoren in plaats van losse schermen, blijft de lijst kort. Doe het scoren met een developer, een tester en iemand uit de business aan één tafel. Elk van hen ziet risico’s die de anderen missen. Deze vragen helpen daarbij.

Een score van 6 of 9 betekent: dit proces hoort in de geautomatiseerde regressieset. Bij een 3 of 4 volstaat een lichtere controle. Een 1 of 2 heeft misschien helemaal geen regressietest nodig.

Hoe kies je een kleine regressieset?

Begin bovenaan je risicolijst en werk naar beneden tot je kritieke processen gedekt zijn. Dan stop je. Schrijf voor elk proces met een hoog risico één betrouwbare test die de hoofdroute van begin tot eind volgt. Voeg tests toe voor de randgevallen met het meeste risico, zoals een geweigerde betaling. Controleer bedrijfsregels waar het kan op de snellere API-laag. Spreek daarna een tijdsbudget af, bijvoorbeeld dat de hele set binnen een uur draait. Zo’n budget dwingt je te kiezen, en daar gaat het juist om. Deze stappen werken in de meeste teams.

1. Maak een lijst van je processen. Kies wat je bedrijf niet kan missen, niet elk scherm.
2. Scoor ze samen. Gebruik de vragen hierboven en spreek per proces één score af.
3. Dek de top af. Eén end-to-end test per kritiek proces, plus de riskantste randgevallen.
4. Loop je oude tests na. Tests die niets van de lijst bewaken, gaan naar een wekelijkse run of verdwijnen.
5. Werk de lijst bij. Doe dat elk kwartaal en na elk incident in productie.

Bij e-commerceklanten zien we vaak het omgekeerde. Er draaien uren aan geautomatiseerde tests, en toch blijven er kritieke incidenten in productie. De processen die er het meest toe doen, zijn nooit van begin tot eind afgedekt. Wij helpen juist een compacte set te bouwen met zoveel mogelijk risicodekking in zo weinig mogelijk looptijd. Voor kritieke systemen geldt hetzelfde. Voor de nieuwe besturingssoftware van de Maeslantkering beschrijft onze Delta Works-case een risicogebaseerde teststrategie op basis van TMap. Die strategie veranderde mee met wat het testen opleverde. Elke regressieset heeft diezelfde gewoonte nodig, want de risicolijst is nooit af.

Wat laat je weg, en wanneer is dat een fout?

Laat tests weg die een klein risico bewaken, een andere test herhalen of steeds falen zonder dat er een echte bug is. Tests schrappen voelt riskant, maar een test die willekeurig faalt, doet meer kwaad dan goed. Mensen leren rode uitslagen te negeren, en dan missen ze ook de echte. In ons stuk over flaky tests lees je waarom dat gebeurt. Onze testers zien nu een nieuwe variant van dit probleem. Sommige teams laten AI veel tests maken, gewoon omdat het makkelijk kan. Een plan voor wat elke test moet bewaken, ontbreekt dan. De set groeit snel, en het aantal tests dat zonder duidelijke reden faalt ook. Het onderzoek van DORA naar test automation komt op hetzelfde uit. Een test is pas nuttig als een fout op een echt probleem wijst.

Risicogebaseerd testen heeft ook grenzen, en die mogen we best noemen. Een risicolijst is zo goed als de mensen die hem maakten, en mensen scoren wat ze kennen. Een proces waar niemand aan dacht, krijgt geen test. Houd daarom twee vangnetten. Exploratief testen door een mens vindt de problemen die geen lijst voorspelde. Acceptatietesten door gebruikers uit de business controleren of de software past bij hoe zij echt werken. Een slimmere regressieset vervangt geen van beide. En bij systemen waar veiligheid op het spel staat, is een kleine set niet het doel. Daar bepaalt risico hoe grondig je test, niet óf je test.

Wat betekent dit voor je team?

De eerste set kiezen kost een ochtend. Hem goed houden is het lastige deel. Elke release voegt processen toe en verandert bestaande, en elke wijziging kan een risico groter of kleiner maken. Iemand moet de lijst bijwerken, de tests aanpassen en weghalen wat er niet meer toe doet. In veel teams is dat werk van niemand. Zo groeit de set langzaam terug naar een hele nacht.

Dat doorlopende werk doen wij met Test Automation as a Service. Samen met je team beginnen we bij de bedrijfsprocessen met het meeste risico, zodat de moeite gaat naar waar het telt. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je team houdt de regie over wat er live gaat. Een TaaS-klant schreef op onze site dat we de business snel begrijpen en daardoor meedenken over wat je wel en niet automatiseert.

Een eerste stap voor deze week: schrijf je tien belangrijkste bedrijfsprocessen op. Geef elk een score voor kans en impact. Kijk dan welke van de bovenste vijf je huidige tests echt afdekken.

Veelgestelde vragen

Wat is het verschil tussen risicogebaseerd testen en regressietesten?

Regressietesten controleert of wat werkte, na een wijziging nog werkt. Risicogebaseerd testen is een manier om te kiezen welke tests je draait, en hoe grondig. Zo houd je een regressieset klein en gericht.

Hoeveel tests hoort een regressieset te hebben?

Daar is geen vast getal voor. Begin bij je kritieke processen en spreek een tijdsbudget af, zoals een uur. Past de set daar niet in, verplaats dan controles naar snellere lagen of schrap tests met een laag risico.

Wie doet de risicoanalyse?

Een klein groepje: een developer, een tester en iemand uit de business. De developer weet wat vaak verandert. De business weet wat het meeste pijn doet. De tester brengt die twee samen.

Hoe vaak werk je de risicolijst bij?

Elk kwartaal, en na elk incident in productie. Werk hem ook bij voor een grote wijziging, zoals een nieuwe koppeling of een nieuw platform.