Vier principes voor een betere implementatie van testautomatisering

implementatie van testautomatisering

In mijn werk als consultant kom ik bij veel organisaties over de vloer die moeite hebben met de implementatie van testautomatisering. Ze willen óf starten met testautomatisering, maar weten niet zo goed hoe ze dat dan moeten aanpakken, óf ze lopen vast in hun huidige werkwijze, omdat ze het gevoel hebben dat er meer uit hun geautomatiseerde tests te halen moet zijn.

Herkenbaar? In dit artikel bespreek ik vier principes die van essentieel belang zijn voor een degelijke, onderhoudbare en toekomstvaste oplossing voor geautomatiseerd testen, maar die (te) vaak te weinig aandacht krijgen.

Testautomatisering is softwareontwikkeling

Het opzetten van een gedegen oplossing voor geautomatiseerd testen, en vervolgens het implementeren daarin van de gewenste tests, is een vorm van softwareontwikkeling. Dat klinkt vanzelfsprekend, maar is het helaas nog niet altijd. Een goede testautomatiseerder moet een heel specifieke verzameling van vaardigheden hebben: hij of zij moet code kunnen schrijven, kunnen nadenken over herhaalbaarheid en onderhoudbaarheid, maar ook een mening hebben over hoe tests het beste kunnen worden geautomatiseerd: op welk niveau, met welke tool, en of een test überhaupt wel geautomatiseerd moet worden.

Daarnaast moet de oplossing zelf ook als software worden behandeld. Denk hierbij aan het onderbrengen van geautomatiseerde tests in versiebeheer en het inruimen van tijd voor het maken en vooral voor het onderhouden van de geautomatiseerde testscripts. Zeker de tijd die dat laatste kost wordt nogal eens onderschat of zelfs helemaal vergeten.

Automatiseer op het juiste niveau

De meeste mensen die iets weten van testautomatisering kennen het model van de testautomatiseringspiramide wel. Dit model geeft aan dat je geautomatiseerde testset moet bestaan uit een brede basis van unit tests, een kleinere middenlaag van integratietests (die bijvoorbeeld de API-laag van een applicatie aanspreken) en een nog kleinere toplaag van (vaak user interface-gestuurde) end-to-end tests. Sommige teams en organisaties hangen zelfs percentages (bijvoorbeeld 70-20-10) aan voor de gewenste verhouding tussen de verschillende testsoorten.

implementatie van testautomatisering

Zo strikt zou je de piramide echter niet moeten interpreteren. Het idee van Mike Cohn achter het model is wel dat je je constant moet blijven afvragen wat de meest efficiënte manier is om een bepaalde test uit te voeren. Daarbij kun je de regel hanteren dat je nooit iets met een end-to-end test moet testen wat je niet ook met een integratietest of zelfs een unittest zou kunnen doen. Hoe lager je in de piramide gaat, hoe eenvoudiger (en dus goedkoper) het is om tests te ontwikkelen en te onderhouden, en ook hoe sneller de tests kunnen worden uitgevoerd en je feedback krijgt over de kwaliteit van je applicatie. End-to-end tests (bijvoorbeeld geschreven met behulp van Selenium) zijn tijdrovend qua opzet, uitvoer en onderhoud, maar hebben zeker hun plek in de totale set van geautomatiseerde tests. Het kan echter heel erg lonend zijn om, als testautomatiseerder, eens verder te kijken dan de user interface, om te zien of er geen effectievere manier is om bepaalde functionaliteit te testen.

Meer is niet altijd beter

Stel, je oplossing voor geautomatiseerd testen is een succes: de tests lopen goed, geven de juiste informatie, zijn effectief en krachtig en versnellen daadwerkelijk je software delivery life cycle (waar ze uiteindelijk toch ook voor bedoeld zijn). Dan kan het erg verleidelijk zijn om maar tests toe te blijven voegen, zonder kritisch te blijven op wat je nu precies test. Je moet je echter voor elke test die je toevoegt blijven afvragen:

  • Is het erg als de functionaliteit die ik met deze test afdek niet correct werkt? (is deze test noodzakelijk?)
  • Dek ik deze functionaliteit nog niet voldoende af met andere tests? (ontstaat er geen overlap als ik deze test toevoeg?)
  • (En nog een keer) is dit de meest effectieve manier om deze functionaliteit te testen?

Elke nieuwe test brengt namelijk een beetje extra onderhoud met zich mee, net als een beetje extra tijd die het kost om de testset uit te voeren. Zodra je niet meer kritisch bent op welke tests je toevoegt, en op welke manier, bestaat het risico dat je uiteindelijk met een grote verzameling geautomatiseerde tests zit die dan misschien wel goed lopen, maar die veel onderhoud vragen en waarvan het maar de vraag is of je niet met bijvoorbeeld de helft van de tests net zoveel testdekking kunt behalen.

Wees niet bang te snoeien in je tests

En als je dan toch bezig bent met het beschouwen van testautomatisering als een vorm van softwareontwikkeling, vergeet dan ook niet regelmatig je tests te testen. Doe dit niet alleen op het moment dat je ze ontwikkelt, maar herhaal dit periodiek om te kijken of je testset nog steeds zo krachtig is in het vaststellen van bevindingen als ze waren op het moment dat je ze schreef. Veranderingen in je applicatie kunnen er namelijk onbedoeld voor zorgen dat je tests misschien nog steeds slagen, maar niet meer falen in geval van een fout in je applicatie.

Voor je unit tests zou je dit bijvoorbeeld kunnen doen door het toepassen van mutation testing. Dit is een techniek die kleine veranderingen in je applicatie aanbrengt en vervolgens kijkt of de bijbehorende unit test faalt. Wanneer de unit test na het aanbrengen van de wijziging nog steeds slaagt, is deze blijkbaar niet in staat de wijziging te detecteren. Op deze manier kun je vaststellen of je testsuite unit tests bevat die geen toegevoegde waarde hebben. Voor integratie- en end-to-end tests bestaat er helaas (nog) geen vergelijkbare manier voor het geautomatiseerd bepalen van de kwaliteit en effectiviteit ervan. Maar ook hier loont het om periodiek door je verzameling tests heen te lopen en je af te vragen:

  • Voegt deze test nog steeds de waarde toe die hij op het moment van schrijven had?
  • Is deze test nog steeds in staat de fouten in de applicatie die hij zou moeten detecteren, ook daadwerkelijk te rapporteren?

Wees niet bang om tests waarvoor het antwoord niet twee keer volmondig ‘ja’ is weg te gooien. Een compacte, krachtige testset die snel feedback geeft over de kwaliteit van je applicatie is nog altijd effectiever dan een grote, logge testset die veel tijd en verzorging nodig heeft!

Delen:

Bas Dijkstra

Bas Dijkstra helpt organisaties met het verbeteren van hun testinspanningen door het slim toepassen van tools. Hij heeft 10 jaar ervaring met het ontwerpen en implementeren van oplossingen voor testautomatisering bij uiteenlopende organisaties.
Bekijk de LinkedIn pagina van Bas Dijkstra