De testpyramide is een van de meest geciteerde modellen in QA, en een van de meest verkeerd toegepaste. De vorm is geen doel op zich, ze is een vertaling van waar risico typisch zit.
Veel teams behandelen de vorm als een doel op zich: veel unit tests, wat minder integratietests, en zo weinig mogelijk end-to-end tests, punt.
Maar de vorm is geen doel. Ze is een vertaling van waar risico typisch zit in een klassieke architectuur. Verschuift die architectuur, dan verschuift het risico mee, en je teststrategie zou dat moeten volgen.
Drie situaties waarin afwijken de juiste keuze is
API first architectuur
Contract en API integratietests worden belangrijker omdat veel risico in de samenwerking tussen services zit. Daardoor verschuift de balans soms bewust richting meer integratietests.
Legacy code zonder tests
Begin met enkele end-to-end of karakterisatietests als vangnet. Daarna voeg je unit tests toe terwijl je refactort. De klassieke volgorde omdraaien is hier de veiligere weg.
UI zware applicaties
Bij complexe front-end logica, denk aan canvas of drag-and-drop interacties, verschuift een groter deel van de teststrategie terecht naar component en UI-tests.
De vuistregel
De testpyramide blijft een goed startpunt, juist omdat ze een reële aanname vastlegt: in een klassieke, gelaagde architectuur zit het meeste risico op het laagste niveau, en daar test je dus het meest. Het probleem ontstaat pas wanneer teams die vorm blijven volgen nadat hun architectuur al lang is veranderd.
Stel jezelf daarom niet de vraag "volgen we de pyramide nog", maar "waar zit ons risico vandaag, en dekt onze teststrategie dat af". Soms is het antwoord exact de klassieke vorm. Soms niet. Beide zijn prima, zolang het een bewuste keuze is en geen gewoonte die niemand nog in vraag stelt.
Herkenbaar?
We nemen je testaanpak door en zeggen eerlijk waar de winst zit. En waar niet.
Plan een gesprek