Hoe houden we het testwerk bij? Dat is de grote vraag waar testteams mee worstelen.
Want elke nieuwe functionaliteit brengt risico's met zich mee zoals verouderde testscenario's, toenemende bugs en eindeloze uren extra werk voor het testteam.
Resulterend in vertraagde releases, frustratie bij teams en een dalende productiviteit.
Met een aanpassing in de testarchitectuur vond ik een gepaste oplossing voor dit probleem.
In deze blog neem ik je mee in hoe ik als test automation architect een structurele keuze heb gemaakt om de testautomatisering te verbeteren.
Met deze verandering is de testautomatisering schaalbaar en groeit het moeiteloos mee met het software systeem.
Waarom ons testproces steeds achter de feiten aanliep
Ik werk met meerdere teams samen welke werken volgens het API first principe, dit maakt het een centraal onderdeel binnen het product.
De backend levert de API, de frontend gebruikt deze, en het testteam zorgt voor de kwaliteitsborging. Klinkt ideaal maar in de praktijk liep het testteam, en vooral de test automation engineers, continu achter op de software.
De meeste defecten ontstonden in deze API laag.
Door het snel doorvoeren van features en bugfixes wijzigde de API regelmatig, waardoor de tests en het testframework vaak niet meer actueel waren. Dit zorgde voor veel handmatig herstelwerk, frustratie bij de teams en het risico dat fouten pas laat worden ontdekt.
Een herkenbare situatie voor veel organisaties en een goede uitdaging voor de test automation architect om hier een passende oplossing voor te vinden.
Een klein idee dat onze testaanpak radicaal veranderde
Samen met een test automation engineer ben ik gaan nadenken over een oplossing op de constante test achterstand.
Een gewaagd idee kwam ter tafel; “Kunnen we de code voor de API-clients en Data Transfer Objects (DTO) genereren?”
Ik wist precies welke tooling hiervoor te gebruiken is. Orval, een TypeScript tool die code genereert doormiddel van de OpenAPI specificatie. Hierdoor gebruikt het testframework altijd de meest up-to-date HTTP-calls, Types en DTO’s.
Vanuit architectonisch perspectief past deze aanpak perfect in onze visie op onderhoudbaarheid en herbruikbaarheid.
Door de code generatie op basis van de OpenAPI specificatie te automatiseren, elimineren we manuele afhankelijkheden en verlagen we de complexiteit van het testframework.
Na kort overleg vonden we dit het proberen waard en besloten tijd te reserveren voor een proof of concept.
We namen een kleine set bestaande API tests en pasten deze aan om de gegenereerde code te gebruiken.
Door dit te combineren met de test runner Vitest hadden we al snel een proof of concept voor een demo gemaakt.
Tijdens de demo aan het testteam waren de reacties niets anders dan positief.
“Dit scheelt ons zoveel tijd, handmatig bijwerken van alle endpoints hoeft niet meer!”,
“Hiermee kunnen we ons eindelijk focussen op slimme testscenario’s”.
Het enthousiasme van de collega’s was aanstekelijk. De testers zagen direct de voordelen en de test automation engineers stonden te popelen om deze nieuwe aanpak breed in te gaan inzetten.
De opvallende kwaliteitswinst
Wat deze oplossing architectonisch sterk maakt, is dat het uitgaat van een contract-first principe: De documentatie als bron van waarheid. Dit leidt tot betere afstemming tussen teams en voorkomt dat testlogica versnipperd raakt. Daarnaast bevordert het hergebruik van gegenereerde code tot een consistente implementatie en verlaagt het de onderhoudslast drastisch.
De investering om bestaande tests aan te passen was minimaal vergeleken met de winst die we er mee hebben behaald. De tests zijn nu vele malen makkelijker te onderhouden.
De grootste winst voor mij was dat het backend-team was direct onboard met het idee. Ze zagen nu nog meer het belang en de voordelen van een goede en actuele OpenAPI specificatie.
Ons succes bleef niet onopgemerkt. Ook de frontend teams gingen Orval gebruiken om hun client code te genereren.
Nu zien alle teams het OpenAPI document als een soort contract, en discrepanties in de documentatie worden erkent als bug.
De kwaliteit van het gehele platform is gestegen en dat is waar ik als test automation architect het alemaal voor doe.
Goede documentatie is een no-brainer
Deze aanpak laat zien dat je met een slimme, relatief eenvoudige oplossing direct verschil kunt maken. Niet alleen werd ons werk leuker en efficienter, maar het vertrouwen tussen teams groeide. Door deze verbeterde relatie steeg de kwaliteit van de software.
Gegenereerde code op basis van OpenAPI? Voor ons bleek het een ware uitkomst.
Minder handmatig werk, minder fouten, en vooral meer tijd voor innovatie.
Mijn belangrijkste tips:
- Zie documentatie niet als bijzaak, maar als integraal onderdeel van je product.
- Durf te investeren in tools die code of documentatie genereren en zorg voor een solide toepassing; Bij goed gebruik betaalt de initiële investering zich snel terug.
- Deel de oplossing met andere teams: Succes motiveert.
Let's connect!
Wil je ontdekken hoe een doordachte testarchitectuur jouw organisatie helpt om sneller en meer kwaliteit te leveren? Neem contact met me op, ik denk graag mee!