Je vraagt een kleine aanpassing aan in je webapplicatie: een extra veld op een formulier, een andere berekening van de verzendkosten. De wijziging gaat live en lijkt prima te werken. Tot een week later blijkt dat de facturen sindsdien een verkeerd bedrag tonen. Herkenbaar? Dit soort onverwachte bijwerkingen is precies wat geautomatiseerde tests moeten voorkomen. In dit artikel leggen we uit wat geautomatiseerd testen is, welke soorten tests er zijn en waarom het ook voor jou als opdrachtgever relevant is.
Waarom software "vanzelf" stukgaat
Maatwerksoftware is zelden af. Er komen nieuwe wensen bij, regels veranderen, koppelingen met andere systemen worden aangepast en onderliggende frameworks krijgen updates. Elke wijziging raakt code die weer samenhangt met andere code. Hoe groter en ouder een applicatie, hoe lastiger het wordt om met zekerheid te zeggen dat een aanpassing nergens anders invloed op heeft. Daarom heeft een applicatie ook na de livegang structureel onderhoud nodig.
Handmatig testen helpt, maar heeft grenzen. Niemand klikt na elke kleine wijziging alle schermen, rollen en uitzonderingssituaties opnieuw door. Dus wordt vooral getest wat er veranderd is, en blijven bijwerkingen elders onopgemerkt. Juist daar komen geautomatiseerde tests in beeld.
Wat is geautomatiseerd testen?
Een geautomatiseerde test is een klein stukje code dat controleert of een ander stukje code doet wat het moet doen. Een test kan bijvoorbeeld vastleggen: "Als een klant drie producten van €10 bestelt met 21% btw, dan is het totaalbedrag €36,30." Die controle draait met één commando, in seconden, en zo vaak als je wilt.
Het grote voordeel: tests worden niet moe, slaan niets over en vergeten geen uitzonderingen. Een applicatie met een goede set tests kan na elke wijziging volledig worden gecontroleerd, ook de onderdelen waar niemand aan gedacht heeft.
De verschillende soorten tests
Niet elke test is hetzelfde. In de praktijk onderscheiden we grofweg drie niveaus:
Unittests
Unittests controleren een klein, afgebakend onderdeel van de code, zoals één berekening of één functie. Ze zijn snel en precies: als een unittest faalt, weet je meestal direct waar het probleem zit.
Feature- of integratietests
Deze tests controleren of meerdere onderdelen goed samenwerken. Denk aan: "Als een ingelogde gebruiker dit formulier verstuurt, wordt er een order aangemaakt in de database en gaat er een bevestigingsmail uit." In Laravel-projecten, waar wij veel mee werken, vormen dit soort tests vaak de kern van de testset, omdat ze dicht bij het echte gebruik van de applicatie liggen.
End-to-end-tests
End-to-end-tests bootsen een echte gebruiker na die door de applicatie klikt in een browser. Ze geven veel vertrouwen, maar zijn trager en gevoeliger voor kleine wijzigingen in de interface. Daarom zet je ze meestal in voor de belangrijkste processen, zoals inloggen, bestellen of betalen.
Een gezonde testset bestaat vooral uit snelle unit- en featuretests, aangevuld met een beperkt aantal end-to-end-tests voor de kritieke paden.
Wat levert het je op als opdrachtgever?
Tests schrijven kost tijd, en die tijd zit in de ontwikkelkosten. Het is dus een terechte vraag wat het oplevert. De belangrijkste voordelen:
- Minder fouten in productie. Problemen worden ontdekt voordat een wijziging live gaat, niet door je klanten of medewerkers.
- Sneller en veiliger doorontwikkelen. Ontwikkelaars kunnen met meer vertrouwen aanpassingen doen, omdat de tests direct laten zien of er iets onbedoeld is veranderd.
- Eenvoudiger updaten. Frameworks en pakketten moeten regelmatig worden bijgewerkt, onder meer om beveiligingsredenen. Met goede tests zie je snel of een update iets breekt.
- Kennis vastgelegd in code. Tests beschrijven hoe de applicatie zich hoort te gedragen. Dat helpt nieuwe ontwikkelaars om sneller in te stappen en maakt je minder afhankelijk van de kennis van één persoon.
- Lagere kosten op de lange termijn. Een fout die tijdens de ontwikkeling wordt gevonden, is doorgaans veel eenvoudiger op te lossen dan een fout die al weken in productie draait en data heeft beïnvloed.
Tests en automatische controles in de ontwikkelstraat
Tests zijn het meest waardevol als ze automatisch en consequent draaien. Daarvoor gebruiken ontwikkelteams een zogeheten CI-pipeline (continuous integration). Bij elke wijziging die een ontwikkelaar aanbiedt, worden automatisch alle tests uitgevoerd. Faalt er een test, dan wordt de wijziging niet doorgevoerd totdat het probleem is opgelost.
Naast tests kun je in zo'n pipeline ook andere controles opnemen, zoals statische code-analyse, controle op codestijl en het signaleren van bekende kwetsbaarheden in gebruikte pakketten. Samen vormen ze een vangnet dat de kwaliteit van je software bewaakt, zonder dat iemand eraan hoeft te denken.
Hoeveel testen is genoeg?
Een veelgehoorde valkuil is het najagen van een zo hoog mogelijk percentage "code coverage": het deel van de code dat door tests wordt geraakt. Dat getal zegt iets, maar niet alles. Een test die code uitvoert zonder de juiste dingen te controleren, geeft schijnzekerheid.
Een pragmatischere aanpak is om te beginnen bij wat het meeste risico draait. Stel jezelf de vraag: welke onderdelen van de applicatie mogen absoluut niet stuk? Denk aan berekeningen van prijzen en facturen, rechten en toegang, en koppelingen met externe systemen. Zorg dat die goed getest zijn, en breid de testset uit naarmate de applicatie groeit.
Bestaande software zonder tests
Heb je een applicatie die al jaren draait maar geen of weinig tests heeft? Dan hoef je niet alles in één keer in te halen. Een werkbare aanpak is om bij elke nieuwe wijziging of opgeloste bug een test toe te voegen. Zo groeit de testset precies op de plekken waar het nodig is. Voor de belangrijkste processen kun je daarnaast gericht een aantal tests laten schrijven, zodat je in ieder geval de kern van je applicatie beschermt.
Twijfel je of een oude applicatie nog de moeite waard is om door te ontwikkelen? Lees dan Doorontwikkelen of opnieuw bouwen? Zo beoordeel je verouderde software.
Vragen die je aan je ontwikkelpartij kunt stellen
Wil je weten hoe het met jouw software is gesteld? Deze vragen geven snel inzicht:
- Worden er geautomatiseerde tests geschreven, en voor welke onderdelen?
- Draaien de tests automatisch bij elke wijziging?
- Wat gebeurt er als een test faalt?
- Hoe wordt getest na een update van het framework of van gebruikte pakketten?
Een goede ontwikkelpartij kan deze vragen helder beantwoorden en laten zien hoe het in de praktijk werkt.
Met vertrouwen doorontwikkelen
Geautomatiseerd testen is geen luxe voor grote softwarebedrijven, maar een basisvoorwaarde voor maatwerksoftware die jarenlang betrouwbaar moet blijven werken. Bij CodeBros maken tests standaard deel uit van ons ontwikkelproces. Ook helpen we bestaande applicaties stap voor stap van een solide testset te voorzien, bijvoorbeeld als onderdeel van applicatiebeheer en doorontwikkeling.
Benieuwd hoe het met de testdekking van jouw applicatie zit? Neem contact met ons op voor een vrijblijvend gesprek.