Door Bert Veldman
Bij een klant in het publieke domein stond ik voor een uitdagende opdracht: het vervangen van een bedrijfs kritische testtool. In deze sector, waar software niet alleen nieuwe functionaliteiten ondersteunt maar ook complexe wet- en regelgeving uitvoert, is een gedegen toolkeuze essentieel. In deze blog neem ik je mee door dit proces aan de hand van het Test Tool Management (TTM) model.
De context: Een dynamische samenleving in de BRP
Stel je voor: een burger verhuist, krijgt een kind of ondergaat een geslachtsverandering. Al deze levensgebeurtenissen landen in de Basisregistratie Personen (BRP). Dit systeem is constant in beweging. Niet alleen door menselijke mutaties, maar ook door nieuwe wet- en regelgeving.
Bij mijn klant in het publieke domein is softwareontwikkeling daarom een continu proces. Maar deze software staat niet op zichzelf. Er is een enorme keten aan partners verbonden met de BRP: gemeentes, de politie, het CBS en pensioenuitvoerders. Al deze partijen wisselen continu data uit.
Inleiding: Het Functionele Domein en de BRP
Om de noodzaak voor een nieuwe tool te begrijpen, moeten we kijken naar de dynamiek van de Basisregistratie Personen (BRP). Mensen in Nederland staan ingeschreven met gegevens als geboortedatum, geslacht, woonadres en gezinssituatie. Omdat het leven dynamisch is, is de BRP constant onderhevig aan mutaties (geboorte, verhuizing, overlijden).
Bijhouders vs. Afnemers
Binnen dit stelsel maken we een essentieel onderscheid tussen twee type ketenpartners:
- Bijhouders (Mutatie van data): Dit zijn veelal de bronhouders, zoals gemeentes. Zij voeren de wijzigingen door in de basisadministratie wanneer een burger een levensgebeurtenis meldt. Zij ‘sturen’ de mutatie de keten in.
- Afnemers (Consumptie van data): Dit zijn instanties die op basis van een pub/sub-mechanisme de relevante gegevens ontvangen om hun eigen taken uit te voeren. Denk aan de politie, het CBS, de Belastingdienst of pensioenvoorzieners.
Een voorbeeld, de bijhouder registeert mijn verhuizing van gemeente A naar B, en de pensioenvoorziener en politie en centraal buro statistiek (CBS) weet dat ook. Of je doet aangifte van geboorte van een Meisje in de gemeente A
De Uitdaging: Ketenorkestratie
Wanneer een wet wijzigt (bijvoorbeeld de registratie van een levenloos geboren kind), moeten zowel de leveranciers voor bijhouders als de afnemers hun software aanpassen. Dat kan dus met meerdere partijen tegelijk zijn. Het berichtenverkeer verloopt asynchroon via een “Berichtendienst” (mailboxserver) tussen de verschillende ketenpartners. Denk bij de mailbox server als een outlook mailboxen die berichten opsparen, verzamelen en periodiek naar de juiste deelnemende mailboxen verstuurd ( 1:-N relatie)
De testtool moet deze complexe orkestratie nabootsen en ondersteunen/valideren:
- Berichtcycli: Een gebeurtenis zoals een verhuizing bestaat uit een samenspel van gerelateerde berichten die in een specifieke volgorde verwerkt moeten worden.
- Validatie: De tool controleert of de berichten voldoen aan het Logisch Ontwerp (LO) — de wettelijke beschrijving van de inhoud, samenhang en controles in de velden.
- Sign-off: Pas als een ketenpartner (biihouder of afnemer) foutloos de testscenario’s in de tool doorloopt, krijgt de softwareleverancier een goedkeuring (implementatieadvies) voor productie.
Het probleem: Oude techniek in een moderne wereld
Het testen van deze keten is complex. Berichten worden asynchroon verstuurd via een zogenaamde ‘Mailboxserver’. Deze berichten uit lange reeksen tekst op vaste posities. Als tester moest je letterlijk tekens uittellen om te zien of de data klopte of de testcase klaarzetten. Dit is foutgevoelig en tijdrovend, omdat elke testrun een andere timestamp in de bestanden heeft en volledig consistent voor de volgende testrun moet worden gemaakt.
Bovendien is de huidige berichten structuur inclusief testtool ‘end-of-life’. De technologie stamt uit de jaren ’90, de ontwikkelaars gaan bijna met pensioen en de programmeertaal is exotisch. Ondertussen moderniseert de hele keten naar RESTfull API’s en JSON. De oude testtool kan dit simpelweg niet aan. Er is dus een nieuwe oplossing nodig.
De methode voor toolselectie: Het TTM-model als kompas
Omdat we voor een publieke instelling werken, is een transparant keuzeproces cruciaal. We kunnen niet zomaar een tool ‘kiezen’. Daarom heb ik ons/het TTM-model gebruikt. Dit model geeft (ook mij) houvast bij het selecteren, implementeren en beheren van testtools.
Het TTM-Model: Een Gestructureerde Aanpak
Test Tool Management (TTM) is een gestructureerd model dat het hele lifecycle management van testtools beschrijft: van behoeftebepaling en selectie tot implementatie, onderhoud en uitfasering. Kort gezegd: “Testtoolbeheer omvat het selecteren, implementeren en onderhouden van softwarehulpmiddelen voor effectief en efficiënt softwaretesten.”
Dit model is cruciaal voor een publieke instelling als deze, omdat het zorgt voor:
- Transparantie: Het keuzeproces is helder en navolgbaar voor alle stakeholders.
- Acceptatie: Beslissers en andere partijen begrijpen de gemaakte keuzes.
- Kwaliteitsborging: Gezien het hoge afbreukrisico (een testfout kan enorme reputatieschade en burgerimpact hebben), is een gedegen en gewogen oordeel over alternatieven essentieel.
De fasering van het TTM-model wordt schematisch weergegeven in de afbeelding hieronder:
Op basis van de fasering van het TTM-model wordt hieronder de klant situatie doorlopen en behandeld:
Fase 1 Strategie
1.1 De probleem analyse
De klant wil middels test automatisering via een tool binnen de keten expliciete kwaliteitsgarantie met de ketenpartners valideren. Dit moet met een testorkestratie tool zijn, die a-synchroon in de keten werkt.
Het probleem is:
De tool is verouderd, end of life en qua testdata complex te onderhouden; onderhoudskosten hoog. De onderliggende code/keten wordt ook veranderd, van tekst berichten naar Json formaat, dus moet bijbehorende tooling ook aangepast, is er een beter alternatief?
De strategie, in de keten willen we met testtooling de testresultaten van ons zelf en de keten partners betrouwbaar valideren en orchestreren. Hiervoor maken we gebruik van tools. De huidige is end of life en moet vervangen, met evt. optimalisaties (wie onderhoud, welke inspanning, testdekking en mogelijkheden).
Fase 2 : Architectuur
2.1 De plek in het ecosysteem
De tool fungeert als centrale spil in een beveiligd domein. Terwijl interne tests bij de klant plaatsvinden met tools als ReadyAPI en RobotFramework (vaak met stubs & drivers), is voor de ketentest een omgeving nodig die een end-to-end simulatie biedt. Dit op basis van vooraf gedefinieerde berichten inclusief hun afhandeling in de keten.
2.2 Wat is data-orkestratie?
In deze context is orkestratie het stroomlijnen van dataprocessen: verzamelen, transformeren en afleveren van berichten in de juiste volgtijdelijkheid. De nieuwe tool moet deze ‘flow’ binnen het ecosysteem foutloos coördineren, dus sequenties, afhankelijkheden, orkestratie van a-synchroon verkeer, berichten beheersing, triggers inclusief de afhandeling van foutpaden. Ook het maken van run rapportage, wat is verwerkt en welke fouten / afwijkingen (goed en fout) zijn gedetecteerd.
Fase 3 Selectie
Het selectieproces: Van Longlist naar Shortlist
Het selectieproces is de kern van de TTM-aanpak. Om te voorkomen dat we een tool zouden kiezen op basis van ‘onderbuikgevoel’ of marketinghypes, hebben we dit opgedeeld in een brede literatuur verkenning en een specifieke toetsing.
3.1 De Desktop Studie: Van Longlist naar Shortlist
De eerste stap was een brede marktscan om een longlist van test-orkestratie tools op te stellen. Hierbij hebben we bewust buiten de gebaande paden gekeken om een vertekend beeld (bias) te voorkomen. Onze bronnen waren:
- Online Research: Analyse van de ‘Top 5’ lijsten op platformen zoals Google, YouTube, Reddit en gespecialiseerde tech-blogs (zie tabel)
- Peer Reviews & Community: Interviews met testspecialisten en een analyse van actuele vaardigheden op jobboards en LinkedIn-profielen.
- Interne Inventarisatie: Welke tools zijn er al binnen de organisatie aanwezig (zoals ReadyAPI, Tosca, RobotFramework en Postman)?
- Objectiviteitsborging: Door verschillende bronnen naast elkaar te leggen, voorkomen we dat we enkel tools selecteerden die toevallig ‘trending’ waren op één platform.
Opmerking: AI-tools zijn in dit onderzoek buiten beschouwing gelaten, omdat deze binnen de afgeschermde zones van het publieke domein op dit moment niet toegankelijk zijn.
Opmerking II. In het onderzoek is ook het JAVA framework geïntroduceerd als alternatief. Deze staat uiteraard niet in blogs of andere desk top studies, want het is zelfbouw ipv een markt beschikbare tool. Dit alternatief is ingebracht door de klant interne testdienst, om de complexiteit van orkestratie te mitigeren, en hergebruik testcases incl. achterliggende domein logica vanuit de testers in te kunnen zetten.
Omdat uit een brede search ( what is the best RestAPI testtool including orchestration) veel tools naar voren komen, heb ik gekozen gestructureerd elke tool te beoordelen.
3.2 De Criterialijst: De Meetlat
Om de tools op de longlist objectief te kunnen scoren, hebben we een lijst met harde en zachte criteria opgesteld. Deze criteria bepaalden of een tool überhaupt door mocht naar de POC-fase.
Technische & Operationele Criteria:
- Open Source vs. Licentie: Wat zijn de kosten op lange termijn en de mate van vendor lock-in?
- Connectivity: Kan de tool volledig stand-alone draaien op een testmachine in een afgeschermde zone, of is een actieve internetverbinding vereist?
- Platform-onafhankelijkheid: Past de tool binnen de huidige infrastructuur zonder dat de hele architectuur op de schop moet?
Gebruik & Onderhoud:
- Ease of Scripting: Hoe snel kan een tester nieuwe scenario’s scripten en bestaande testware onderhouden?
- Leercurve & Ervaring: Hebben de huidige testers al ervaring met de tool of de onderliggende taal? Dit is cruciaal voor de opstarttijd.
- Migratiekracht: Hoe makkelijk kunnen bestaande testcases en data worden overgezet naar de nieuwe oplossing?
Strategisch & Architectuur:
- Rapportage: Biedt de tool voldoende inzicht voor een formeel ‘implementatieadvies’?
- Architectuur-principes: Voldoet de tool aan de kernwaarden en kwaliteitsdoelen van de klant (denk aan beveiliging en schaalbaarheid)?
Hieronder de lijst van tools vergeleken met criteria,
Waarbij een aantal uit longlist zijn verwijderd vanwege non match met eisen ; wel een orkestratie tool, maar specifiek op BI omgevingen, vereist Microsoft Dev OPs ontwikkelstraat etc:
3.3 Bepalen van shortlist POC:
Uit de desktop analyse is een grote lijst gekomen aan tools die geschikt zijn voor data orkestratie in keten verband. Mar elke tool heeft wel een bepaald doel en ook pre-condities. Het opstellen van de long list , moet ongefilterd gebeuren (non biassed), vervolgens wel kijken naar de praktische haalbaarheid (doelstelling, precondities, product karakteristiek) naar de klant situatie en problematiek.
De klant wilde graag sturing en betrokkenheid in het proces, dus heb ik ervoor gekozen deeltijdse rapportage en workshops te houden, om de verschillende stakeholders (testdienst, DEV OPS team, stuurgroep, de afdeling kwaliteit ) aangehaakt te houden en tot een gerdagen advies te kunnen komen.
Los van de in de markt “bekende” tools heeft de klant interne testdienst ook een oplossingsrichting middels een JAVA framework, wat feitelijk een upgraded versie is van de huidige testtooling vwb functionaliteit, orkestratie, toegankelijkheid binnen de DMZ (beveiligde interne zone binnen het intranet) en onderhoudbaarheid ondervangen.
Het doel? Een shortlist maken van kandidaten die we in een Proof of Concept (POC) wilden testen.
De Longlist omgezet naar Shortlist
| Tool | Keuze POC | Analyse |
| ReadyAPI | Ja | Al bekend bij de klant, maar vraagt veel handmatig data-onderhoud. |
| Java Framework | Ja | Krachtig voor data-generatie en uitstekende conversie van oude tests. |
| Kestra | Ja | Veelbelovende orkestratie-tool, maar vraagstuk ivm internet toegang. |
| Postman | Nee | Wordt uit gefaseerd vanwege security-risico’s. |
| Azure Data Factory | Nee | Onrealistisch, want vereist een volledig Azure-platform. |
| Airflow / Dagster | Nee | Te specifiek gericht op BI; minder op orkestratie van berichten. |
| Tosca | Nee | Meer gericht op schermflows dan op complexe datageneratie. |
De volgende tools zijn in een POC meegenomen
- ReadyAPI
- JavaFramework
- Kestra
Alle POC tools gewogen obv gelijke criteria en hebben ze een gelijke set aan testcases moeten automatiseren.
Fase 4 POC
4.1 De Proof of Concept (POC)
Een tool moet op papier goed zijn, maar in de praktijk nog beter. Tijdens de POC moesten de tools een specifieke ‘use case’ doorlopen: de verhuizing van een burger tussen twee gemeentes. gelijke testcase voor alle tools
De tool moest voldoen aan harde criteria:
- REST API ondersteuning: Verplicht voor de nieuwe standaard.
- Orkestratie: Berichten moeten in de juiste volgorde en asynchroon verwerkt worden.
- Beveiliging: De tool moet werken binnen een afgeschermde omgeving (zonder internet).
- Schaalbaarheid: Geschikt voor grote sets testdata.
4.2 Conclusie POC
De ontknoping: Waarom een Java Framework?
Na de POC en een uitgebreide analyse viel de keuze op een Java Framework.
Waarom?
- Kestra bleek te afhankelijk van een internetverbinding, wat in de beveiligde zones van de klant een probleem is.
- ReadyAPI was technisch geschikt, maar het data onderhoud van duizenden testcases bleef te arbeidsintensief. Immers, voor elke run , date stamp en wetswijziging moet je dan de testcases inclusief orkestratie af,
- Het Java Framework won op alle fronten:
Waarom het Java Framework?
- Kennis: Java is een bekende taal onder de huidige testers.
- Onderhoud: Het omzetten van de oude ‘gestringde tekst’ naar nieuwe scripts ging soepel.
- Toekomst: Het biedt de flexibiliteit die nodig is voor de complexe BRP-logica.
Fase 5 & 6: Implementatie & Beheer
De klant heeft besloten het Java Framework verder uit te rollen. Hiermee wordt de administratieve last van het ‘tekstposities tellen’ in de oude tool vervangen door een robuuste, code-gedreven oplossing.
Binnen de klant organisatie heeft de TestDients een belangrijke centrale regie en uitvoerings rol. Dat betekend afstemming met de ketenpartners over testvoorbereiding en uitvoering, data sets en verwerken van nieuwe en aangepaste flows/wet en regelgeving. OM daarmee de expliciete ketenkwaliteits garantie te kunnen aanbieden aan de bijhouders en afnemers. Naast de wetgevende instanties in ministerie.
Voor de volledigheid is het ook goed om aan te geven welke partijen en stakeholders zijn betrokken en geraadpleegd in het onderzoek, per fase in het TTM model
Welke rollen/stakeholders in welke fase van TTM model
| TTM Fase | Rollen | Verantwoordelijkheid |
| Architectuur | Beheerder | Toetst aan het technische beleid van de klant. |
| Strategie & Selectie | Tooleigenaar (Testmanager / PO) | Bepaalt de koers en het budget. |
| POC & Gebruik | Gebruiker (Testengineers) | Voert de praktijktest uit en script de testcases. |
| Verwijdering | Beheer / Gebruiker | Faseren de oude mailboxserver uit. |
Terugblik
Het gebruik van het TTM-model bood mij het nodige houvast in een complex landschap. Politiek en technisch. Het zorgde voor transparantie naar de stakeholders en een gewogen oordeel in een omgeving met een hoog afbreukrisico. De transitie van ‘legacy’ tekstberichten naar een modern Java-framework markeert een nieuwe fase in de robuuste ketenkwaliteit binnen de BRP-keten.
Als “contributer”in de werkgroep moet je natuurlijk je eigen vlees keuren, en het was prima.
Daarnaast, met behulp van het TTM model voorkom je schijn van partijdigheid en wordt je gestructureerd door het hele traject begeleid.
En, omdat de BRP gerekend wordt tot de bedrijfs kritische infrastructuur (kind krijgen, verhuizen etc) , was 100% kwaliteit een “given” en kon ik de klant geruststellen dat de gekozen oplossing past in de doelstellingen. Ondersteunend in orkestratie, passend in DMZ, eenvoudig onderhoud, data migratie oude test cases, beheer intern, lage kosten. En, acceptatie door de stakeholders.