Onderhoudbaarheid van de Testautomatisering

Redactie: Gerben de la Rambelje
Auteur: Mustafa Canbaz ● m.canbaz@maxmin.eu

Afgelopen donderdag 26 oktober hebben we met de Werkgroep Testautomatisering (WTA) van TestNet over het onderwerp ‘Onderhoudbaarheid van de testautomatisering’ gebrainstormd. Uitgangspunt van de discussie was: wat zijn nou de randvoorwaarden om de testautomatisering dusdanig in te richten dat deze ook op de langere termijn onderhoudbaar is. De discussie was nog niet gestart en de Piramide van Mike Cohn kwam al snel om de hoek kijken.
 

Test Piramide Mike Cohn

Aan de basis van de ‘Test Piramide van Mike Cohn’ staat het unittesten. Unittests moeten volgens het concept het fundament vormen voor een solide testautomatiseringsstrategie en vertegenwoordigt als zodanig het grootste deel van de piramide. GUI-testen worden bovenaan de piramide geplaatst, omdat het wenselijk is dit zo weinig mogelijk te doen. Daarnaast moet de GUI-test gericht zijn op de happy flow, waarin niet alle paden worden doorlopen.

Als de unittests het fundament van de testautomatisering zijn, dan zou je ook kunnen zeggen dat dit een developers aangelegenheid is en de inbreng van de testers hierin minimaal is. Developers moeten dus software en (automated) testware ontwikkelen. Voor het opzetten van een goede testautomatisering is het dus belangrijker dat hiervoor testware development capaciteit beschikbaar is, om op die manier een solide basis neer te zetten, die ook onderhoudbaar is.
 

Beheer en standaarden testautomatisering

Een ander belangrijk aspect van de onderhoudbaarheid van de testautomatisering is dat er goede standaarden en richtlijnen zijn. Voorbeelden van standaardisatie zijn:

• Code standaarden – reviews;
• Comments toevoegen in de testnavigatie-code/script;
• Naamgevingsconventie;
• Behandel testautomatisering als code en beheer het ook als zodanig;
• Taggen van testcases om run coverage flexibel te houden voordat een test draait;
• Ownership van zowel de testcases als de automatische testscripts goed beleggen, inclusief de langetermijnwaarborging.

 Investeren in:

• Startpunt van een testomgeving, inclusief alle (pre-condities) testdata, snel terug te kunnen zetten om zodoende automatische testen te draaien in CI/CD, met bijvoorbeeld Docker;
• Zorg dat de testcoverage altijd goed in beeld is; bijvoorbeeld met behulp van een requirements management tooling.

Broken windows syndrome

Als de testautomatisering er staat en het is bijvoorbeeld onderdeel van de dagelijkse built, dan is het belangrijk dat de focus er is om deze te onderhouden als onderdeel van het Software Development proces. Als bijvoorbeeld een built faalt, omdat er een testscenario een negatief resultaat oplevert, dan moet hier direct naar gekeken worden. Is dat niet geval, dan kan het Broken windows syndrome (BWS) optreden[i].

Wegwerp oplossing

Een andere strategie voor de onderhoudbaarheid van de testautomatisering kan zijn om je testscripts snel op te stellen. Als ze niet meer werken weg te gooien, om vervolgens weer snel nieuwe scripts te maken. Moeilijkheid met deze strategie is dan wel dat je moet oppassen dat de testcoverage wel intact wordt gehouden.
 

Tot slot

Het was een hele interessante bijeenkomst van de WTA, die veel stof heeft doen opwaaien. We zijn over dit onderwerp zeker nog niet uitgepraat want hoe ga je de testautomatisering beleggen in een organisatie. Doe je dat centraal of decentraal?
Credits: dank aan onze gastheer Maurice Siteur en alle andere WTA leden, die deel hebben genomen aan deze intense brainstormsessie.
[i] Het Broken windows syndrome houdt kortgezegd in dat als je een gebroken raam niet repareert, al snel de volgende ramen zullen sneuvelen: http://www.omgevingspsycholoog.nl/broken-window-theory/