Ghislain Gabrielse, Test Automation Engineer bij Sogeti en Damayanti Kanwar, Software Developer in Test bij Sogeti hebben bij autoleasebedrijf Alphabet een Test Data Service gebouwd voor complexe microservice-omgevingen. Hiermee weten ontwikkelteams wat de status van testsets is. De data wordt automatisch opgeschoond en aangeleverd voor het testen van microservices.
Uitdagingen door groei
Wat is een microservice? Ghislain: “Dit is een service die speciaal gemaakt is voor één specifiek doel, bijvoorbeeld voor het berekenen van de btw van winkelproducten. Omdat dergelijke services heel klein zijn, hebben we er bij Alphabet ook veel, ongeveer 43.” Toen Ghislain en Damayanti begonnen bij Alphabet, waren dit er echter veel minder. “In het begin werd bij elke service die we deployden ook testdata geleverd. Maar al snel groeide het aantal services en het aantal teams dat daaraan werkte. Inmiddels houden 150 man in zestien teams zich tegelijkertijd bezig met het aanpassen van verschillende microservices.” Dat bracht nieuwe uitdagingen voor het testen en aanleveren van betrouwbare testdata met zich mee.
Geen vertrouwen in data
“Het testen duurde steeds langer”, zegt Damayanti. “Eerst moesten testers nagaan welke microservices de data bevatten die ze nodig hebben. Na de test moest de status van de testdata gecheckt worden: is deze dataset veranderd en nog wel bruikbaar voor een eventuele volgende test?” Steeds meer testen faalden doordat de data niet meer bruikbaar was. “Daardoor kelderde ook het vertrouwen: na een gefaalde test wil je toch een paar keer opnieuw testen om er zeker van te zijn dat een service nu wel goed werkt.” Dat startte een negatieve spiraal: testers vertrouwden steeds minder op de aanwezige testdata, waardoor ze deze sets vaak niet meer gebruikten. Er moest voor elke test een nieuwe dataset gemaakt worden, waardoor het testen nog langer duurde.
Gebouwd op vier pijlers
Om de testers snel te voorzien van betrouwbare data, ontwikkelden Ghislain en Damayanti een speciale Test Data Service (TDS). Deze service baseerden ze op vier principes:
- Testdata moet automatisch gecreëerd worden.
- Testdata moet losgekoppeld worden van testuitvoer.
- De status van testdata moet bijgehouden worden.
- Datasets moeten geversioneerd worden.
Hoe werkt TDS?
Ghislain schetst de werking van TDS in hoofdlijnen: “Ten eerste voert de service eenmalig statische testdata in, die bruikbaar blijft na een test. Ten tweede voert de service continu dynamische testdata in. Deze is niet meer bruikbaar na een test. Bestaande API-calls leveren deze testdata aan verschillende applicatie-databases. Dit zijn dezelfde API’s als de front-end gebruikt, maar dan losgekoppeld daarvan. Daardoor werken ze veel sneller: in enkele seconden vinden ongeveer twintig API-calls plaats.”
Automated Test Execution
Na de API-calls werkt TDS de status van gebruikte testdata bij en bewaart deze in een eigen database. Hierin kunnen testers altijd terugvinden of een dataset beschikbaar en bruikbaar is. Het daadwerkelijk testen van microservices verloopt via testautomatisering. Ghislain legt uit: “De datasets worden automatisch aangeleverd voor geautomatiseerde testuitvoer. Deze testautomatisering communiceert met TDS door telkens te vragen: ik heb deze test, heb je geschikte testdata voor me? Zo ja, dan levert TDS unieke ID’s die bruikbaar zijn in een test.”
TDS voor microservices heeft duidelijke voordelen ten opzichte van de traditionele aanpak: het vertrouwen in testsets groeit, testdata is van betere kwaliteit en daarmee kun je microservices, sneller en op verschillende manieren testen. Wil je weten hoe je een dergelijke TDS-omgeving technisch inricht?
Bekijk de video van de QX Day-presentatie ‘Availability of test data in a complex microservices environment’
Meer weten?
Ben je benieuwd hoe we organisaties kunnen helpen hun Quality Engineering naar het volgende level te tillen? Bekijk dan onze Quality Engineering & Testing oplossingen en services.
Quality Engingeering & Testing services
