De testpiramide, in mensentaal.

Je kent het gevoel misschien. Er wordt iets aangepast aan je systeem, en een week later blijkt dat er ondertussen iets anders stuk is gegaan dat maanden probleemloos werkte. Elke nieuwe aanpassing voelt daardoor als een gok, en een release wordt iets om tegenop te zien in plaats van naar uit te kijken.

Dat is meestal geen pech en ook geen kwestie van slordige mensen. Het is een symptoom van waar er getest wordt. En laat dat nu net iets zijn dat je kan beoordelen, ook al schrijf je zelf geen tests.

Daarvoor bestaat een handig beeld: de testpiramideDe testpiramide is een vuistregel voor het testen van software: veel kleine, snelle en automatische tests onderaan, en steeds minder grote, trage tests naarmate je hoger komt.. Stel je een piramide voor met drie lagen. Onderaan, breed en stevig, zitten heel veel kleine controles die elk een klein stukje van de software nakijken. Ze draaien automatisch en in enkele seconden, dus bij elke wijziging opnieuw. In het midden zitten wat minder, maar grotere controles die nagaan of de onderdelen goed samenwerken. Bovenaan, in de smalle top, zit een handvol controles die de hele toepassing doorlopen zoals een gebruiker dat zou doen. Die laatste zijn waardevol, maar traag en gevoelig, dus je houdt er bewust weinig van.

De vorm is het hele punt. Breed en goedkoop onderaan, smal en duur bovenaan. Sommige teams draaien die piramide per ongeluk om. Ze automatiseren nauwelijks en controleren vooral op het einde, door vlak voor een release alles met de hand door te klikken. Dat wankele geval wordt spottend het ijshoorntje genoemd: een klein beetje stevigheid onderaan en een grote, zware bol bovenop. Het is traag, het breekt makkelijk, en het mist net de fouten die niemand toevallig heeft aangeklikt.

Waarom onderaan testen zo veel oplevert, is trouwens geen mening. Het is dezelfde redenering als de wet van BoehmDe wet van Boehm zegt dat een fout duurder wordt naarmate je ze later ontdekt en herstelt, en dat die kost exponentieel oploopt.: hoe later je een fout vindt, hoe duurder ze wordt om recht te zetten, en dat loopt snel op. Een fout die een kleine automatische controle meteen bij het schrijven opmerkt, kost bijna niets. Diezelfde fout die pas bij je klanten bovenkomt, kost een veelvoud, plus het vertrouwen dat je even kwijt bent.

Wat betekent dat concreet voor jou? Je hoeft geen enkele test te schrijven of te lezen. Je moet gewoon de juiste vraag stellen aan wie jouw software bouwt of onderhoudt: hoe testen jullie, en gebeurt dat automatisch bij elke aanpassing of pas met de hand op het einde? Het antwoord zegt je meer dan je zou denken. Een team dat rustig antwoordt dat de meeste controles automatisch meelopen, geeft je een heel ander vooruitzicht dan een team dat vertelt dat ze voor elke release een paar dagen manueel nakijken.

En als je wil doorvragen: een gezonde aanpak herken je eraan dat een nieuwe versie uitbrengen iets alledaags is in plaats van een evenement. Waar de piramide klopt, durven mensen aanpassen, want ze horen het meteen als er iets misloopt. Waar ze omgekeerd staat, wordt er zo weinig mogelijk aangeraakt uit schrik om iets te breken, en precies die voorzichtigheid maakt een systeem op termijn duurder en stroever.

Je moet dus geen tester worden om hier iets aan te hebben. Je moet alleen weten dat de vorm van de piramide bestaat, en af en toe vragen of ze bij jou nog altijd rechtop staat.