20 okt 2026 De testpiramide: welke test hoort waar, zodat je testset snel blijft

In het kort: De testpiramide is een model om je geautomatiseerde tests over drie lagen te verdelen. Onderin veel snelle unittests, in het midden minder API-tests en bovenin een kleine set UI-tests. Een testset met die vorm draait in minuten, faalt om duidelijke redenen en houdt je releases bij.

Een testset die een hele nacht nodig heeft, remt juist de releases af die hij moet beschermen. De meeste trage testsets hebben dezelfde vorm. Honderden UI-tests klikken door schermen, er is een dun laagje API-tests, en bovenop ligt een stapel handmatige checks. De testpiramide laat in één plaatje zien wat daar mis aan is. En hoe je het repareert, test voor test.

Wat is de testpiramide?

De testpiramide is een model dat laat zien hoe je geautomatiseerde tests over drie lagen verdeelt. Mike Cohn bedacht het, en Martin Fowler maakte het bekend. Onderin zitten unittests. Die controleren één klein stukje code, zoals een prijsberekening, en draaien in milliseconden. In het midden zitten API- en integratietests. Die controleren of onderdelen van het systeem goed samenwerken, bijvoorbeeld of een bestelling de juiste gegevens opslaat. Ze slaan het scherm over, dus ze zijn snel en stabiel. Bovenin zitten UI-tests, ook wel end-to-end tests genoemd. Die klikken door de applicatie zoals een gebruiker dat doet. Ze geven per test het meeste vertrouwen, maar ze zijn traag en breken zodra een scherm verandert. De vuistregel is eenvoudig: veel tests onderin, minder in het midden en maar een paar bovenin.

Die vorm draait om snelle feedback. Een developer die binnen een paar minuten hoort dat er iets stuk is, lost het meteen op. Hoort hij het pas de volgende ochtend, dan zit hij alweer in iets anders.

Waarom staan zoveel testsets op hun kop?

De meeste testsets worden topzwaar omdat UI-tests de makkelijkste start zijn. Een tester kan een gebruikersflow automatiseren zonder de code erachter te kennen. Elke bug die erdoor glipt, krijgt een nieuwe end-to-end test. Na een jaar lijkt de testset op een ijshoorntje. Veel UI-tests, weinig API-tests, weinig unittests en daarbovenop nog handwerk. Bij e-commerceklanten zien we dit patroon vaak. Lange UI-testsets vertragen de pipeline, en API- en UI-tests bestaan naast elkaar zonder duidelijk plan. De API-tests zijn er wel, maar worden niet gebruikt waar ze het sterkst in zijn: het bewaken van businesslogica en koppelingen.

Dat ijshoorntje kost je op vier manieren.

• Trage feedback. Een volledige UI-run duurt uren, dus hij draait alleen ’s nachts of vlak voor een release.
• Ruis. UI-tests hangen af van timing, browsers en testdata, dus veel ervan worden flaky tests die falen zonder echte bug.
• Dubbel werk. Dezelfde regel wordt via het scherm in tien verschillende flows gecontroleerd.
• Onderhoud. Eén aangepaste knop kan tientallen tests tegelijk laten falen.

Welke test hoort op welke laag?

Zet elke check op de laagste laag die het probleem nog kan vangen. Gaat een check over een regel, zoals een korting of een btw-tarief, dan hoort hij onder het scherm. Gaat hij over de vraag of een echte gebruiker zijn route kan afmaken, dan hoort hij bovenin. Met die ene vraag sorteer je de meeste tests. Je UI-laag blijft er ook klein door, want het meeste wat UI-tests controleren is eigenlijk logica. De tabel laat het zien met een webshop als voorbeeld.

In de middelste laag valt voor de meeste teams het meeste te winnen. API-tests controleren businesslogica zonder browser, dus ze zijn snel en zelden flaky. Daarom is API testen de beste plek om prijzen, kortingen en voorraadregels te bewaken. Wil je per laag codevoorbeelden zien, dan is The Practical Test Pyramid van Ham Vocke een goed stuk om te lezen.

Hoe breng je een topzware testset terug naar de testpiramide?

Je brengt een testset stap voor stap in balans, niet met één grote herbouw. Begin bij de tests die je de meeste tijd kosten, en verplaats hun checks laag voor laag naar beneden. Laat de testset ondertussen gewoon draaien, zodat je vangnet blijft staan. Deze stappen werken in de meeste teams.

1. Meet. Zet je UI-tests op een rij, met hoe lang elke test duurt en hoe vaak hij faalt zonder echte bug.
2. Zoek dubbelingen. Kijk welke regel via het scherm in veel flows terugkomt.
3. Verplaats checks naar beneden. Herschrijf regelchecks als API- of unittests. Houd één UI-test per belangrijke route.
4. Splits de runs. Draai de snelle lagen bij elke wijziging en de volledige UI-set ’s nachts.
5. Ruim zorgvuldig op. Verwijder tests die geen echt risico meer bewaken.

Snelle en zware checks uit elkaar halen levert snel iets op. In onze Data Warehouse-case draaiden de functionele tests op kleine datasets die op productie leken. De zware datakwaliteitschecks draaiden apart, op grote datasets. De geautomatiseerde testruns gingen van dagen naar minder dan 30 minuten.

Eén kanttekening: de piramide is een richtlijn, geen wet. Sommige systemen hebben weinig eigen logica, zoals een webshop op een SaaS-platform. Daar ligt meer gewicht bij API- en end-to-end tests, en dat is prima. En geen enkele laag vervangt mensen. Exploratief testen vanuit een echte gebruiker en acceptatietesten door de business blijven mensenwerk.

Wat betekent dit voor je team?

Een testset in balans brengen is geen eenmalige opruimactie. Elke nieuwe feature levert tests op, en iemand moet bepalen waar die horen. Iemand moet ze ook betrouwbaar houden en weghalen wat er niet meer toe doet. In veel teams komt dat werk terecht bij wie er toevallig tijd voor heeft, en tijdens een release heeft niemand tijd. Zo groeit het ijshoorntje langzaam terug.

Dat doorlopende werk pakken we op met Test Automation as a Service. Samen met je team bouwen we een compacte testset die de meeste risico’s dekt in zo kort mogelijke tijd. Regels zitten op de API- en unitlaag, en een kleine UI-set dekt de routes die ertoe doen. Je tests draaien elke nacht, en wij houden ze betrouwbaar. De testset blijft van jou, gedocumenteerd en overdraagbaar, en je team houdt de regie over wat er live gaat.

Eerst zelf beginnen? Pak deze week je tien traagste UI-tests. Schrijf per test op welke regel hij echt controleert, en of een API-test dat sneller kan.

Veelgestelde vragen

Wie heeft de testpiramide bedacht?

Mike Cohn beschreef hem in zijn boek Succeeding with Agile. Martin Fowler en anderen maakten hem breed bekend. Het idee is niet veranderd: veel kleine, snelle tests en weinig trage.

Hoeveel UI-tests heb je nodig?

Daar is geen vast getal voor. Mik op één UI-test per belangrijke gebruikersroute, zoals inloggen, bestellen en betalen. Controleer de rest waar het kan op een lagere laag.

Is de testpiramide nog actueel?

Ja, als richtlijn. Tools hebben UI-tests sneller gemaakt, maar ze zijn nog steeds trager en kwetsbaarder dan API-tests. De piramide helpt je kiezen waar een nieuwe test hoort.

Wat is het verschil tussen de testpiramide en de testing trophy?

De testing trophy legt meer gewicht bij integratietests en minder bij unittests. Het model komt uit de frontendwereld. Beide modellen zijn het over de hoofdzaak eens: houd de trage UI-laag klein.