Ober, er zit een bug in mijn software!

Is het nu echt zo moeilijk om die fouten te voorkomen?

donderdag 29 juni 2023

Waarom is deze berekening nu alweer niet goed? Waarom crasht de applicatie nu weer als dit bericht wordt verstuurd? Waarom blijft mijn app nu weer hangen? Wie herkent deze verzuchtingen niet, als gebruiker of als tester? Is het nu echt zo moeilijk om die fouten te voorkomen?

De oplossing, ondersteunt door theorie en praktijk, is voor de hand liggend: meer en beter testen. Had de fout waar je tegen aan bent gelopen niet eerder in het proces gevonden en voorkomen kunnen worden?

Waarom wordt er niet meer getest?

Wat houdt organisaties tegen om meer te testen? Vaak is men zich er niet echt bewust van is dat er veel meer testgevallen nodig zijn. In dit geval wordt hier dus ook niet op gestuurd. Dat is wel nodig, zeker gezien de toenoemende complexiteit van software. Tijdsdruk aan het eind van het proces en beperkte resources spelen hierbij ook een rol.

Is software nu echt zo complex? Software complexiteit is onzichtbaar en lastig vast te pakken. Een landkaart als metafoor voor software: stel je de software voor als een landkaart met vele snelwegen, B-wegen, landweggetjes, fietspaden, tunnels, bruggen en veerboten. Een beetje interessant stuk complexe software is zeker zo complex als het wegennet van Nederland. In de praktijk gebeurt het testen vaak op een deel van de hoofdfunctionaliteit, zeg maar een tiental snelwegroutes. Dit wordt ook wel risico-gebaseerd testen genoemd. Met een beetje mazzel worden er ook nog wat uitzonderingen als bruggen en veerboten getest. Het testen gebeurt vooral handmatig, en bij elke nieuwe versie van de landkaart (de software), springt men in de auto en rijdt dezelfde verzameling routes af.

Als de complexiteit van je software te vergelijken is met het Nederlandse wegennet, en je wilt zeker weten dat de landkaart klopt met de werkelijkheid, kan je je voorstellen dat een tiental, honderdtal of zelfs duizendtal testen niet voldoende is. Dan is het ook niet zo verwonderlijk dat er af en toe iets misgaat.

Hoe kan je het beter doen?

Om meer en beter te kunnen testen is testautomatisering noodzakelijk. Dit is ook al heel lang bekend. In 1999 schreef Kent Beck al zijn beroemde boek: eXtreme Programming Explained, waarin hij best-practises beschrijft van de decennia daarvoor, zoals testautomatisering (in het bijzonder unit-testing). Enkel handmatig testen is echt niet meer voldoende, het kost ook te veel tijd.

Goede technieken die hierbij kunnen helpen zijn Behavior Driven Design (BDD) en Test Driven Design (TDD). TDD betekent dat je met een testgeval begint voordat je de code schrijft. Dit zorgt ervoor dat er voor elke regel code testgevallen zijn die de functionaliteit beschrijven en afdekken. Een speciale vorm hiervan is BDD, dat zich op de gedragscenario’s (behavior) vanuit gebruikersoogpunt richt. Ook deze worden vastgelegd voordat er gebouwd wordt. Tijdens de bouw worden deze BDDs onderhouden.

BDD en TDD zorgen er beide voor dat er:

BDD en TDD zijn hulpmiddelen, het doel is te komen tot een voldoende grondige aanpak om iets zinnigs te kunnen zeggen over de validatie en verificatie van software.

De Axini aanpak

BDD en TDD (scripting in zijn algemeenheid) zijn momenteel de meeste toegepaste technieken om testen te automatiseren. De uitdaging die deze technieken erbij geven is de vele testgevallen die efficiënt onderhouden moeten worden. Dat is iets waar Axini goed bij kan helpen. Axini implementeert de test-first aanpak door het maken van gedragsmodellen, ook wel bekend als Model Driven Design (MDD) met Model Based Testing (MBT), de volgende stap van BDD/TDD, maar dat is iets voor een ander artikel.

Wil je meer weten? Neem contact met ons op of volg ons op LinkedIn.