3.      De organisatie is er klaar voor

Er moet binnen de organisatie voldoende kennis aanwezig zijn om een testautomatisering raamwerk op te kunnen zetten. Tests automatiseren betekent een verandering in de rol van de tester die eerst zijn werk handmatig uitvoerde. Nu wordt er van een tester veel meer technische kennis gevraagd. Niet alleen de tester krijgt te maken met een veranderende werkwijze. In Agile teams zal elk teamlid in staat moeten zijn om tests te ontwerpen, te monitoren en eventueel ook te programmeren. Er moet dan ook draagvlak gecreëerd worden voor deze veranderingen binnen de organisatie.

4.      De juiste tooling is geselecteerd

Het is van groot belang om de juiste testtooling te kiezen voor de automatisering. Wat de tool moet kunnen, is afhankelijk van de scope en het doel van de testautomatisering. Populaire tools hebben vaak een grote community, waarin veel bruikbare informatie wordt verdeeld. Een aantal (test)tools op de markt zijn gebaseerd op Behaviour Driven Development (BDD), waardoor je testcases in ‘begrijpelijke’ taal kan opstellen. Met deze aanpak is het ook voor niet-technische teamleden mogelijk om testcases te begrijpen en eventueel zelf te schrijven.

Het loont ook om een testtool te kiezen die in dezelfde programmeertaal is geschreven als de applicatie die getest moet worden. Ontwikkelaars kunnen dan ondersteuning bieden aan andere teamleden als deze hulp nodig hebben bij het automatiseren van de tests. Bouw je een applicatie in Java, kies dan ook voor een testtool die gebaseerd is op Java.

5.      Er is grip op de test set

Een goed raamwerk opzetten om tests te kunnen automatiseren is belangrijk, maar het onderhouden van deze tests en testdata is net zo belangrijk. Organisaties die testautomatisering toepassen, onderschatten vaak de inspanning die nodig is om de regressietest-set te onderhouden. Door bijvoorbeeld wetswijzigingen of veranderende behoeften vanuit de stakeholders, is het zaak om tests bij te blijven werken en weer actueel te maken. Herleidbaarheid van testgevallen naar een gebruikersbehoefte is daarin essentieel.  Dit vergemakkelijkt het onderhoud aan de opgebouwde regressietest-set aanzienlijk.

Maak ook inzichtelijk en openbaar wat de status is van de testgevallen in de regressietest-set, dit vergroot de betrokkenheid en beleving binnen ontwikkelteams en bij stakeholders.

De volgende stap: Continuous Integration/delivery

Als de organisatie eenmaal succesvol testautomatisering heeft toegepast, dan is het tijd voor de volgende efficiency-slag: het toepassen van Continuous Integration/Continuous delivery (CI/CD).

CI/CD is het automatiseren van diverse handelingen in een ontwikkeltraject, die ervoor zorgen dat code snel en veilig gezet kan worden naar een (productie-like) omgeving. In deze handelingen zitten dan vaak ook de geautomatiseerde tests. Als de ontwikkelaar klaar is met het schrijven van code dan kan hij deze inchecken. Er wordt vervolgens een ‘pakketje aan software’ gemaakt. Op dit pakket worden een aantal Unit tests gedaan. Als deze Unit tests succesvol zijn, dan wordt de software naar een (test)omgeving uitgerold en worden er geautomatiseerde tests op gedaan. Deze stappen van uitrol en test kunnen zich herhalen totdat software succesvol naar productie is gezet, zonder dat daar handmatige acties tussen hebben gezeten.

De herhaalbaarheid van stappen maakt het mogelijk om kleine vernieuwingen live te brengen zonder dat er een lange doorlooptijd is van een handmatige regressietest over het gehele systeem. Via deze CI/CD-aanpak is het dus mogelijk om snel, maar gecontroleerd, nieuwe software naar productie op te leveren en snel feedback op de kwaliteit te krijgen. Ontwikkelaars zijn blij omdat ze maar kleine stukjes hoeven te bouwen en testen, en opdrachtgevers zijn blij omdat de time-to-market aanzienlijk korter is.