Heel kort door de bocht werken de meeste ICT-teams als volgt. Een aantal mensen (business analisten) denken na over wat een programma (anders) moet doen en ze beschrijven dit gewenste gedrag in een serie documenten. Daarna gaan developers ermee aan de slag, ze bedenken de juiste oplossing om het gewenste gedrag te bereiken en maken een applicatie of passen er eentje aan. Uiteindelijk zijn er testers die verifiëren of het vertoonde gedrag ook wel overeenkomt met het beschreven gedrag, ieder verschil is een bug. Een bug wordt opgelost door het gedrag aan te passen (hetzij het beschreven gedrag, hetzij het vertoonde gedrag).

Continue levering

Bijna alle software die DSW Zorgverzekeraar gebruikt, maken en testen wij zelf. De nieuwe release van alle applicaties vindt een keer per kwartaal plaats, maar sinds enige tijd werken we toe naar continuous delivery. Dit houdt in dat zodra er een nieuw stuk functionaliteit wordt opgeleverd (of een bug wordt gerepareerd), dit vrijwel direct doorgevoerd wordt in de productie-versie van de applicatie. Een belangrijke voorwaarde in deze procesverandering is het testproces. Immers, wanneer er wekelijks of dagelijks een nieuwe versie van de applicatie beschikbaar kan zijn, moet het testproces ook zo snel mogelijk kunnen worden afgerond. Bij iedere nieuwe versie van de applicatie, zou de oude functionaliteit nog een keer gecontroleerd moeten worden. De nieuwe wijzigingen voor scherm A zouden namelijk best impact kunnen hebben op scherm F. Om dat te testen doen we voor deze functionaliteit een regressietest waarin we alle schermen van A tot en met F doorlopen. Momenteel is hier een testperiode van vijf weken per kwartaal voor beschikbaar, maar voor continuous delivery zou deze regressietest maximaal enkele uren mogen kosten, zonder naar een lagere dekking te gaan.

Testen schrijven én ontwikkelen

Om deze regressietijd in te korten, zet DSW nu in op grootschalige test-automatisering. En dit is waar de functie van Testdeveloper om de hoek komt kijken. De Testdeveloper hangt precies tussen de developers en de testers in en probeert een zo groot mogelijk deel van de regressietest te automatiseren. Dit doen we door middel van functionele systeemtests, die iedere nacht automatisch worden afgespeeld. Op die manier ziet het ontwikkelteam iedere ochtend in hun inbox of de wijzigingen van gisteren functionaliteit kapotgemaakt hebben. Een simpele systeemtest, opgesteld door een analist of test(develop)er, ziet er zo uit: 

Zoals je ziet zijn deze testgevallen simpel in normale-mensentaal beschreven, zodat ook niet-ontwikkelaars weten wat er wel en niet getest wordt. Iedere zin komt overeen met een stukje code (die door een ontwikkelaar gemaakt moet worden) en door de blauwe keywords weet het computerprogramma waar die stukjes code gezocht moeten worden. De zinnen (stappen) zelf zijn een soort puzzelstukjes die stuk voor stuk overeenkomen met een stukje code dat door een ontwikkelaar is gemaakt. Hoe meer stappen er bestaan, hoe meer mogelijkheden er zijn voor nieuwe testgevallen. Natuurlijk kunnen analisten/testers ook nieuwe stappen voorstellen. De stappen zelf zijn op een generieke manier opgezet, zodat ze makkelijk hergebruikt kunnen worden in verschillende testjes. De door een (test)developer geschreven implementatie van een simpele stap zou er zo uitzien:

Op deze manier willen we automatische systeemtesten schrijven voor al onze zelfgemaakte systemen. Omdat het systeemtesten zijn, wordt ieder contact van een applicatie met een andere applicatie doorgeknipt, waardoor de tests beheersbaar blijven (en er zijn nog een berg andere voordelen). De doelstelling is om voor ieder afzonderlijk systeem een dekkende lijst met tests te maken. Naast deze systeemtesten bestaan er ook nog dagelijkse ketentesten (die de communicatielijntjes tussen afzonderlijke applicaties testen). Op deze manier weten we iedere dag zeker of er vorige dag niets kapotgegaan is en kunnen we de kwaliteit van onze applicatie veiligstellen. En als onze versie van vandaag minstens zo goed is als onze versie van gisteren, is er eigenlijk geen enkele reden waarom we niet naar productie zouden kunnen met de versie van vandaag.

Jouw nieuwe uitdaging?

Het proces van testautomatisering brengt flink wat uitdagingen met zich mee, zowel op technisch als op organisatorisch gebied. Denk aan afstemmen met testers en ontwikkelaars, puzzelen in de systemen en testautomatisering organisatiebreed stevig op de agenda houden.