Ready

Net zoals een huis een goede fundering nodig heeft, moet er voor testautomatisering ook een goede basis zijn. Waarom wordt er gekozen voor testautomatisering? Is dat om bestaande uitdagingen binnen het ontwikkeltraject op te lossen? Of is het ter ondersteuning en versterking van de bestaande teststrategie? Er zijn verschillende redenen om testautomatisering toe te passen binnen een organisatie. En die redenen bepalen voor een deel ook de wijze waarop testautomatisering het beste toegepast kan worden. Een paar van deze redenen zijn:

• Fast feedback is één van de meest voorkomende redenen om te automatiseren. Door een specifieke testset na elke build of merge naar develop te draaien. Krijg je direct inzicht in mogelijke bevindingen en kunnen deze ook gelijk opgepakt worden. Dit maakt het ontwikkelproces efficiënter en maakt de stap naar continue integratie (CI/CD) mogelijk.
• Kostenbesparing op lange termijn is ook een mogelijke reden. Automatische tests hoeven ten slotte maar 1 keer opgesteld te worden en kunnen daarna herhaald worden. Uiteraard kost het opzetten en onderhouden van die scripts tijd. Maar op de lange termijn voorkomt het repetitief handmatig testwerk wat veel tijd kost. Daarnaast geeft het ook de ruimte om de focus te leggen op meer complexe tests of exploratory testing.
• Handmatig testen kost niet alleen veel tijd. Maar is ook gevoelig voor fouten. Een teststap kan overgeslagen worden. Of de testdata is niet volledig of correct klaar gezet. Nauwkeurigheid en vergroten van de testdekking is dan ook een vaak voorkomende reden om bepaalde tests te automatiseren.

En zo zijn er nog meer redenen om testautomatisering toe te gaan passen. CI/CD, Performance, schaalbaarheid, herbruikbaarheid.

Het is van belang dat een organisatie hierover nadenkt. Goede testautomatisering is een grote investering. Niet alleen in geld, maar ook in tijd, kennis en ervaring. En als het niet goed geïmplementeerd wordt, dan kan het uiteindelijk juist kwaliteit, tijd en geld gaan kosten. In plaats van opleveren. Kortom, er moet een valide business case zijn om testautomatisering te introduceren.

Wanneer de business case duidelijk is, moet gekeken worden of de organisatie er technisch ook klaar voor is. Is de infrastructuur geschikt om tests te automatiseren? Zijn er voldoende resources om tests te kunnen automatiseren? Moeten er meerdere testomgevingen en databases beschikbaar zijn of wordt er juist gebruik gemaakt van containerhosting? Ook hierbij is het van belang dat er goed wordt nagedacht. Welke mogelijkheden biedt de huidige infrastructuur en kan daarop doorgebouwd worden. Of is er juist behoefte aan een nieuwe infrastructuur.

Set

De organisatie is er klaar voor. Er is nagedacht over de reden en de infrastructuur ligt er ook. Dan is het van belang dat de teams er ook klaar voor zijn. En dat begint bij de teamleden. Is er voldoende kennis en ervaring voor testautomatisering. En zo niet, is dat dan te bereiken door het volgen van opleidingen of het aannemen/inhuren van technische testers.

De juiste tooling is ook van belang. Er zijn verschillende tools verkrijgbaar, sommige betaald maar veelal ook open source. Welke tool het beste gebruikt kan worden is afhankelijk van verschillende factoren. Onder andere de kennis en ervaring binnen het team. Maar ook de te testen applicatie. Gaat het om een webapplicatie waar de focus ligt op de GUI, of wil je vooral berichtenverkeer testen tussen applicaties.

Veel tools zijn ook gebaseerd op Behaviour Driven Development. Waardoor testcases in begrijpelijke taal opgesteld kunnen worden. Bijvoorbeeld door bepaalde teststappen in een keyword op te nemen. Of door gebruik te maken van Gherkin (given… when… and… then…). Als de tests ook door niet technische testers gebouwd of onderhouden moeten worden. Of als de leesbaarheid van belang is. Dan zijn dit soort tools een goede optie.

Een testtool waarin geprogrammeerd wordt in dezelfde taal als de applicatie is ook aan te raden. Hierdoor kunnen de ontwikkelaars de testers ondersteunen. En kunnen zij ook makkelijker tests bouwen en onderhouden.

Om goede automatische tests te kunnen schrijven is goede functionele documentatie nodig. Documentatie met duidelijke acceptatiecriteria. Waarbij de testgevallen te traceren zijn naar de functionele behoefte. Dit maakt het makkelijker om de tests te onderhouden wanneer er functionele wijzigingen zijn.

Automate(?)

Ik hoorde het vrij recent nog bij een opdracht. Een collega die aangaf dat je alle tests die geautomatiseerd kunnen worden ook moet automatiseren. En ik kon het niet meer oneens zijn met die gedachte.

In dat team was de jarenlange tendens geweest om alles te automatiseren. Wat resulteerde in een testset van honderden tests die een paar uur duurde om te draaien. Niet heel erg efficiënt en al helemaal geen fast feedback dus. Tests die elkaar inhoudelijk overlappen omdat telkens dezelfde stappen werden uitgevoerd met als enige verschil de laatste teststap. Het onderhoud was dan ook een ramp, want 1 wijziging in de functionaliteit. Betekende het wijzigen van tientallen tests in de test-set.

Maar ook een vals gevoel van kwaliteit. Automatische tests, checken eigenlijk alleen wat je weet. Wat in de functionele documentatie staat. Of wat je door ervaring en kennis kan deduceren. Maar hetgeen dat je niet weet, wordt nooit gevonden. Dit kan alleen door exploratory tests uit te voeren. Ook het aantal tests zegt niets over de kwaliteit. Slechte tests voegen geen enkele waarde toe. Het draait niet om de aantallen, maar om een goed doordachte testdekking.

Om te voorkomen dat je als team straks met een automatische test-set zit die eigenlijk te groot is om nog efficiënt te zijn. Die niet of nauwelijks onderhoudbaar is waardoor er weinig  tijd overblijft voor exploratory testen. Is het van belang bij elke test af te wegen of deze van waarde is voor de automatische test.

Dit kan onder andere door een product-risico-analyse uit te voeren. Waarbij je besluit alleen de testscenario’s met een gemiddeld of hoog risico te automatiseren. Of door testautomatisering in te zetten als manier om snel testdata of een bepaalde pre-situatie klaar te zetten.

Er wordt nog wel eens vergeten hoe belangrijk het is om naast automatisch testen – waarbij we alleen valideren wat we weten – ook exploratief te testen, waarbij we juist de focus op het onbekende leggen. Tests automatiseren is noodzakelijk in de huidige markt. Maar de mate waarin je dat doet is afhankelijk van heel veel factoren.

Wil jij advies over de mogelijkheden die testautomatisering jouw organisatie kan bieden. Hoe dit een onderdeel kan worden van de bestaande teststrategie. Welke tooling gebruikt kan worden. Aarzel dan niet op contact met ons op te nemen.