Zo stel je een goede testautomatisering architectuur op

Net als bij softwareontwikkeling kunnen ook bij testautomatisering de gevolgen van een slechte architectuur groot zijn. Enkele symptomen die we vaak horen zijn: 

• Lange doorlooptijd voor de ontwikkeling van testautomatisering en een lage ROI omdat de oplossing niet flexibel genoeg is om bepaalde zaken aan te passen;
• Veel foutieve en onbetrouwbare informatie door een hoge instabiliteit van de testuitvoer;
• Geen mogelijkheid om de testcase uitvoer te parallelliseren.

Als je deze symptomen wilt bestrijden moet je een paar stappen terugzetten en de situatie opnieuw bekijken. Pas dan kun je verbetermogelijkheden zien en actie ondernemen. Binnen Salves doen we lopend onderzoek naar een goede fundering van testautomatisering, gebaseerd op software-architectuurprincipes. In dit artikel vatten we de belangrijkste lessen samen.

Wat is architectuur?

Architectuur kun je vergelijken met een bouwtekening. De architectuur beschrijft welke technische onderdelen op welke manier worden gebruikt en hoe die onderdelen met elkaar verbonden zijn. Een architectuurdocument is vaak een levend document dat de gewenste situatie beschrijft en waarin mogelijke risico’s snel in kaart worden gebracht evenals de mogelijke oplossingen hiervoor. Zo’n document gaat helpen om de verdere ontwikkeling van softwareoplossingen helder uit te leggen in het grotere geheel. 

Een degelijke architectuur heeft invloed op kwaliteit, stabiliteit en uitbreidbaarheid van de softwareoplossing. Het wordt gezien als een leidraad van het software development-proces. 

Het mag duidelijk zijn dat architectuur iteratief wordt ontwikkeld. Dit houdt in je regelmatig moet controleren of de architectuur nog aansluit op de realiteit. Aanpassingen kunnen bijvoorbeeld betrekking hebben op een reorganisatie, nieuwe functionaliteit of veranderende klantwensen. Wat veel mensen zich te weinig realiseren, is dat veranderingen in het fundament (lees architectuur) altijd tijd vergen en kosten met zich meebrengen. Ook daarin wijkt de (door)ontwikkeling van software niet af van de bouw van een huis. Als de fundering of constructie niet zwaar genoeg is om een nieuwe aan- of opbouw te dragen, moeten eerst deze ‘onzichtbare’ investeringen worden gedaan om de nieuwbouw op een succesvolle wijze te integreren.

Hoe stellen we de architectuur van testautomatisering op?

In een architectuur leg je de volgende zaken vast:

• Wensen en belangen van de klant. Denk hierbij aan de eisen waaraan de software moet voldoen. Naast bedrijfs- en functionele eisen benoem je hierin ook technische eisen zoals beveiliging en performance.
• De organisatie van de technische componenten. Welke technische onderdelen of programmeertalen zijn er? Hoe communiceren ze met elkaar? Welke afhankelijkheden moeten we rekening mee houden? Hoe kunnen we dit duidelijk beschrijven en visualiseren?
• Risico’s en mitigatie. Welke risico’s zien wij in de architectuur en hoe gaan we ze mitigeren?

Aan de hand van deze thema’s stel je vervolgens de architectuurprincipes op, met daarin kernwaarden of kwaliteiten waar een principe aan zou moeten voldoen. Deze principes bewaken de wensen en belangen van de klant en de organisatie. 

We hanteren de volgende principes voor de architectuur van testautomatisering:

1. Operatie: Het implementeren en uitvoeren van de testautomatisering.
   Mogelijke kernwaarden zijn: gebruiksvriendelijkheid vanuit de integraded development environment (IDE), foutgevoeligheid tijdens de uitvoer, toekomstbestendigheid, integratie met CI/CD, draagvlak door het team, schaalbaarheid en veiligheid.
2. Testen: Het opzetten en ontwikkelen van kwaliteitscontroles in de testautomatisering.
   Mogelijke kernwaarden zijn: het ontwerpen of modelleren van testcases, onderhoud, parallellisatie, testdata, testdekking, testcase onafhankelijkheid, snelheid en testbaarheid van de systems under test (SUT). 
3. Ontwikkeling: de softwareontwikkeling om kwaliteitscontroles te kunnen uitvoeren.
   Mogelijke kernwaarden zijn: gebruikersvriendelijkheid in verificaties, mocking of stubbing, versionering, debugging, refactoring, coding standards en practices als KISS, DRY, YAGNI en SOLID 
4. Feedback: het rapporteren van kwaliteitscontroles en de uitkomst hiervan interpreteren.Mogelijke kernwaarden zijn: begrijpen van de testresultaten, logging, mate waarin de rapportage informatief is en de snelheid van de testuitvoer.

De gelaagdheid van de testautomatisering architectuur

Naast de principes en kernwaarden van de testautomatisering is het belangrijk om een goede gelaagdheid in de testautomatisering aan te brengen om de bovenstaande principes te kunnen hanteren. 

We onderscheiden de volgende vragen die gaan helpen om een gepaste oplossing te formaliseren. 

1. Waarom moeten we controleren? Wat is de wens?
   Dit noemen we vaak de specificatie- of testlaag. Denk hierbij aan:  
   a. Functionele testbeschrijvingen waarin de scenario’s duidelijk worden gemaakt;
   b. Vertaling van functionele beschrijving naar executeerbare stappen.
2. Wat moeten we controleren? Welke stappen nemen wij?
   Dit noemen wij vaak de acties- en verificatielaag. Denk hierbij aan: 
   a. Technische objecten waar we acties op moeten uitvoeren (zoals object repositories of page objects);
   b. Technische stappen die we moeten uitvoeren om verificatie te kunnen uitvoeren.
3. Hoe gaan we controleren? Welke middelen gebruiken we om te controleren?
   Dit noemen wij de driver- of aansturingslaag. Denk hierbij aan: 
   a. Technische componenten om systemen aan te sturen (zoals Web, REST, message queus of database bibliotheken);
   b. Technische componenten om bijvoorbeeld testdata of conversies te realiseren.
4. Hoe gaan we de testen uitvoeren en rapporteren? Welke middelen gebruiken we om informatie te voorzien?
   Dit noemen we de uitvoer- en rapportagelaag. Denk hierbij aan: 
   a. Technische componenten om testen te runnen (zoals testrunners, CI/CD);
   b. Technische componenten om de testuitvoer te documenteren (zoals screenshots,                video’s, fout rapportage, etc.).

Architectuur loont

Door regelmatig de raakvlakken met architectuur in de testautomatisering te bespreken en structuur aan te brengen, merken wij bij onze klanten dat veel van de genoemde problemen zijn opgelost. Hieronder een kleine greep van onze observaties:  

• De doorlooptijd voor testautomatisering wordt verlaagd en de ROI stijgt omdat er meer flexibiliteit ontstaat in het aanpassen en uitbreiden van de testautomatisering door de juiste gelaagdheid in de architectuur.
• Door deze snellere doorlooptijd worden de problemen eerder ontdekt en blijven de kosten voor het vinden en oplossen van die problemen laag.
• Er komt steeds minder valse informatie (false positives of false negatives) omdat er stabiliteit ontstaat in de testresultaten.
• Er ontstaan veel mogelijkheden om de testautomatisering te schalen naar eigen behoefte.
• Door de gelaagdheid in de architectuur wordt het duidelijk of er voldoende kwaliteitscontroles worden uitgevoerd op risicovolle applicaties.

Hoe ziet jouw ideale testautomatiseringsoplossing eruit? Hoe staan jouw architectuurprincipes ervoor in de huidige testautomatisering? Wil je graag een antwoord op deze vragen, neem dan contact met ons op voor een Testautomatisering Assessment , gebaseerd op de testautomatisering architectuurprincipes en kernwaarden. Zo vind je de verbeteringen om een goede fundering voor testautomatisering op te zetten.