26 okt 2026 Continuous testing: welke tests horen bij welke stap van je CI/CD-pipeline?
In het kort: Continuous testing betekent dat geautomatiseerde tests bij elke stap van je CI/CD-pipeline draaien, zodat elke wijziging binnen minuten feedback krijgt. Snelle controles draaien bij elke commit, bredere tests bij elke merge en de volledige regressieset elke nacht. Elke stap heeft een tijdsbudget en een duidelijke regel wanneer hij een wijziging tegenhoudt. De meeste teams lopen vast op de tests, niet op de pipeline.
Een CI/CD-pipeline opzetten kost dagen, geen maanden. Genoeg teams hebben er een en wachten toch een week op een release. De code is klaar, de tests nog niet. Sommige controles gaan met de hand, de testomgeving is bezet en maar één persoon weet waarom de nachtelijke run rood werd. Continuous testing dicht dat gat. Het begint met een simpele vraag: welke tests draai je bij welke stap?
Wat is continuous testing?
Continuous testing betekent dat je geautomatiseerde tests meedraaien in de pipeline, bij elke stap, in plaats van in een testfase aan het eind. Een CI/CD-pipeline is de geautomatiseerde route die een wijziging aflegt van de laptop van een developer naar productie. CI staat voor continuous integration: developers voegen vaak kleine wijzigingen samen, en elke wijziging wordt automatisch gebouwd en getest. Het artikel van Martin Fowler over continuous integration legt het nog altijd het helderst uit. CD staat voor continuous delivery: de software is altijd in een staat waarin je hem zou kunnen releasen. Continuous testing laat die twee werken. Elke wijziging krijgt binnen minuten feedback, dus een developer herstelt een fout terwijl de code nog vers is. De beslissing om te releasen rust dan op testresultaten, niet op een onderbuikgevoel na een week handwerk. In de praktijk zijn het veel kleine testruns, elk met een eigen taak.
Testers worden er niet minder belangrijk door. Het herhaalwerk draait vanzelf, zodat mensen hun tijd kunnen steken in werk waar oordeel voor nodig is.
Welke tests draai je bij welke stap van de pipeline?
Draai de snelste tests het vaakst en de traagste het minst vaak. Elke stap in de pipeline krijgt eigen tests, een tijdsbudget en een quality gate. Een quality gate is een regel die een wijziging tegenhoudt als de tests falen. De tabel laat een verdeling zien die in de meeste teams werkt.
| Stap | Wat draait er | Tijdsbudget | Houdt de wijziging tegen? |
|---|---|---|---|
| Elke commit | Unittests en codecontroles | Een paar minuten | Ja. |
| Elke merge | API- en integratietests, een kleine set UI-tests | Ongeveer 15 minuten | Ja. |
| Elke nacht | De volledige regressieset, met end-to-end processen | Uren is prima | Ja, voor de volgende release. |
| Voor de release | Een korte smoketest op de releaseomgeving | Minuten | Ja. |
Een smoketest is een snelle controle of de belangrijkste functies opstarten en reageren. Hij bewijst niet dat alles werkt, alleen dat er niets groots stuk is. In de middelste stappen win je de meeste tijd. Met API-tests controleer je bedrijfsregels en koppelingen zonder browser. Daardoor zijn ze snel en stabiel genoeg voor elke merge. Lange sets UI-tests bewaar je beter voor de nachtelijke run. Bij e-commerceklanten zien we vaak het omgekeerde. Lange UI-testsets en handmatig testen remmen CI/CD af, dus de pipeline wacht op het traagste deel.
Wat houdt continuous testing meestal tegen?
Wat continuous testing tegenhoudt, is zelden de tool. In onze ervaring is de pipeline opzetten het makkelijke deel. Teams lopen vast op alles wat er niet betrouwbaar en automatisch doorheen kan, en dat is bijna altijd de testkant. Vier oorzaken komen steeds terug.
- Het testen houdt het tempo niet bij. Developers leveren sneller dan ooit, zeker nu AI een deel van de code schrijft. De tests groeien niet even hard mee.
- De regressie is nog handwerk. Elke release loopt iemand met de hand na wat al werkte. Dat past niet in een pipeline.
- Omgevingen en data zijn niet klaar. Testdata verandert per run, omgevingen lijken niet op productie en iemand moet dingen met de hand klaarzetten.
- Kwaliteit hangt aan een of twee mensen. Als alleen zij weten hoe de tests en de release echt werken, kun je alleen releasen als zij er zijn.
In ons stuk over waarom QA de bottleneck wordt genoemd gaan we dieper in op de eerste. Kort gezegd: extra testers helpen weinig als de oorzaak in de werkwijze van het hele team zit.
Hoe houd je de tests in je pipeline betrouwbaar?
Een pipeline is alleen nuttig als het team een rode uitslag gelooft. Zodra mensen op “opnieuw draaien” drukken tot het groen wordt, beschermen de gates niets meer. Vier gewoontes houden het vertrouwen hoog. Haal een test die willekeurig faalt meteen uit de gate, en herstel hem binnen een paar dagen. Ons stuk over flaky tests legt de gebruikelijke oorzaken uit. Geef elke rode nachtelijke run de volgende ochtend een eigenaar. Bewaak de tijdsbudgetten: kruipt de merge-stap van 15 naar 40 minuten, dan gaan mensen hem overslaan. En maak de resultaten zichtbaar voor het hele team, niet alleen voor testers. Het onderzoek van DORA naar continuous delivery koppelt zulke snelle, betrouwbare feedback aan zowel snelheid als stabiliteit.
Twee kanttekeningen. Niet elk team hoeft bij elke commit te releasen. Release je één keer per maand, dan loont continuous testing nog steeds, want problemen komen boven op de dag dat ze ontstaan. En geen pipeline vervangt mensen. Exploratief testen vindt wat niemand in een test had gevat. Acceptatietesten door gebruikers uit de business controleren of een wijziging past bij hoe zij werken. Plan allebei in, zeker voor grote releases.
Wat betekent dit voor je team?
Een pipeline draait vanzelf. De tests erin blijven niet vanzelf gezond. Elke sprint komen er functies bij die nieuwe tests nodig hebben, en elke wijziging kan oude tests breken. Iemand moet de set snel houden, herstellen wat willekeurig faalt en de testdata op orde houden. In veel teams ligt dat werk bij wie er tijd voor heeft, en vlak voor een release heeft niemand tijd.
Dat doorlopende werk doen wij met Test Automation as a Service. Samen met je team zetten we backendcontroles, koppelingen en echte end-to-end scenario’s in je pipeline. Je tests draaien elke nacht, en wij houden ze betrouwbaar. De testset blijft van jou, en je team houdt de regie over wat er live gaat. Een TaaS-klant vertelt op onze site dat ze dankzij de geautomatiseerde regressieset kunnen releasen wanneer ze willen.
Een eerste stap voor deze week: kijk naar je laatste drie releases. Schrijf op hoeveel tijd er zat tussen “code klaar” en “live”, en hoeveel daarvan wachten op tests was.
Tests die je pipeline bijhouden, zodat een release nergens op wacht.
Veelgestelde vragen
Wat is het verschil tussen continuous testing en testautomatisering?
Bij testautomatisering draaien tests zonder dat iemand ze met de hand doorloopt. Bij continuous testing draaien die geautomatiseerde tests bij elke stap van je pipeline, met duidelijke regels wanneer ze een wijziging tegenhouden.
Welke tests draai je bij elke commit?
De snelste: unittests en codecontroles die binnen een paar minuten klaar zijn. Tragere API- en UI-tests draaien bij de merge of ’s nachts, zodat developers niet hoeven te wachten.
Wat is een quality gate?
Een quality gate is een regel in je pipeline die een wijziging tegenhoudt als de tests falen. Bijvoorbeeld: geen merge als een API-test faalt. Een gate werkt alleen als de tests erachter betrouwbaar zijn.
Heb je continuous testing nodig als je één keer per maand released?
Ja, het helpt nog steeds. Problemen komen boven op de dag dat een wijziging gemaakt wordt, niet drie weken later. Herstellen gaat dan sneller en goedkoper, want de code is nog vers.