Het is december. Met de feestdagen in het verschiet is het op veel plekken weer een beetje komkommertijd. Tijd om terug te kijken op het afgelopen jaar en vooruit te blikken op wat komen gaat. Niet voor iedereen overigens. Als ik de LinkedIn inbox open, blijkt steeds weer dat het leger van recruiters in IT-land deze maand bepaald geen gas terug neemt en scrollend door de uitnodigingen is automatisering in de testmarkt meer dan ooit de rode draad.
In 2016 hebben we weer van veel van onze klanten de vraag gehad om ze te helpen met testautomatisering. Dat geeft boeiende inzichten over de manier van denken over automatisering van het testwerk. Vaak kwam de vraag: kunnen jullie onze bestaande testen automatiseren? En steeds was mijn wedervraag: ‘Natuurlijk kan dat, maar weet je wel zeker dat je dat wilt?’. In veel gevallen volgt dan een volmondig ‘Ja’, omdat er een beeld bestaat dat het automatiseren van de bestaande regressietest ervoor gaat zorgen dat die 2 testers, die elke sprint weer een dag aan het regressietesten zijn, dan op magische wijze overbodig worden of zich niet meer met de regressietest bezig hoeven te houden.
De praktijk echter laat zien dat het rücksichtslos automatiseren van de testen, die nu met de hand worden uitgevoerd noch leidt tot tijdsbesparing, noch tot meer of beter testen, noch leidt tot blije testers of ontwikkelteams. Waar het wel toe leidt? Teamleden (vaak de test engineers) die vooral bezig zijn met het aan de gang houden van testscripts en het oplossen van fouten in de scripts, waardoor ze niet meer toekomen aan datgene waarvoor ze zijn aangetrokken. Namelijk het inzicht geven in de kwaliteit van dat wat wordt gerealiseerd. Ondertussen neemt de waarde van de testset af, de achterstand van de testen t.o.v. het ontwikkelwerk neemt toe en de velocity van het team daalt zienderogen. Tot zover de reclame voor het automatiseren van bestaande testen.
Op een effectieve manier automatisering toepassen in het testen vraagt een andere teststrategie en -aanpak. Waar we als testspecialisten zijn opgeleid om testsituaties te herkennen en deze te combineren tot zo min mogelijk logische testgevallen, vraagt een aanpak waarin een deel van de controles geautomatiseerd wordt juist om atomische testen. Één test heeft idealiter één verantwoordelijkheid. Dat maakt onderhoud eenvoudiger, defect-analyse eenvoudiger en zorgt ervoor dat een defect op requirement A er niet voor zorgt dat requirement B niet meer wordt aangetoond in de geautomatiseerde test. Met de technische hulpmiddelen die er zijn, kunnen we ook anders kijken naar de applicatie die we testen. Maakt de applicatie gebruik van services of API’s? Dan kunnen we die in veel gevallen gebruiken om, geautomatiseerd, veel sneller en effectiever aan te tonen of businesslogica de verwachte resultaten geeft. Levert een applicatie output op, dan kunnen we in veel gevallen uitgebreide, geautomatiseerde, controles doen op die gegenereerde output. Maar denk ook aan het isoleren van componenten. Is een front-end alleen verantwoordelijk voor presentatie van gegevens, dan is het waarschijnlijk effectiever om ons te beperken tot het aantonen dat de presentatie logica correct is geïmplementeerd, zonder daarbij afhankelijk te zijn van logica in de back-end die wellicht nog niet bruikbaar is voor betrouwbare testen. Ook dit is een typische use case voor het inzetten van geautomatiseerde hulpmiddelen in je testen.
Is het dan nooit een goed idee om end-to-end testen te automatiseren? Dat hangt af van de situatie. Waar het nodig is om integratie aan te tonen, of waar een ketenproces moet worden aangetoond, zullen altijd end-to-end testen nodig zijn. Maar door effectief te automatiseren neemt de hoeveelheid end-to-end testen af. Misschien wel zo ver dat het niet meer loont ze te automatiseren…
Alles bij elkaar bieden geautomatiseerde hulpmiddelen bij het testen legio mogelijkheden om efficiënter en effectiever te zijn dan wanneer handmatig steeds dezelfde testen worden doorlopen. Niet door de handelingen van de tester te automatiseren, maar door automatisering toe te passen op de verschillende relevante onderdelen van het testproces. In de elektronica-wereld snappen ze dit principe gelukkig al jaren: ik denk niet dat de consument zit te wachten op een robot die een stofzuiger kan hanteren, maar liever een stofzuigrobot door het huis ziet gaan.
