29 okt 2026 Testdatamanagement: zo geef je geautomatiseerde tests data waarop ze kunnen bouwen
In het kort: Testdatamanagement is het plannen, aanmaken, beschermen en terugzetten van de data die je tests gebruiken. Voor geautomatiseerde tests is het doel simpel: elke run start vanuit een bekende situatie. Dat vraagt om tests die hun eigen data aanmaken, scripts die de data terugzetten en zorgvuldig omgaan met echte persoonsgegevens. Zonder dat falen tests om redenen die niets met je code te maken hebben.
Een test slaagde gisteren en faalt vandaag, terwijl niemand de code heeft aangepast. Dan blijkt waarom. Een collega gebruikte dezelfde testklant en wijzigde het adres. Of de kortingscode in de test is vannacht verlopen. Zulke problemen kosten elke week uren, en langzaam gaan mensen de testuitslagen minder vertrouwen. Goed testdatamanagement voorkomt de meeste ervan.
Wat is testdatamanagement?
Testdatamanagement is het werk van plannen, aanmaken, beschermen en terugzetten van de data die je tests gebruiken. In het Engels heet het test data management. Testdata is alles wat er moet bestaan voordat een test begint. Denk aan klanten, producten, bestellingen, accounts en instellingen. Bij handmatig testen is rommelige data lastig maar werkbaar. Een tester die de testklant niet meer vindt, pakt gewoon een andere. Een geautomatiseerde test kan dat niet. Hij verwacht precies de data waarvoor hij geschreven is, en faalt als die veranderd is. Voor automatisering is het doel dus dat elke run vanuit een bekende situatie start. Bij e-commerceklanten zien we dit vaak. Geautomatiseerde tests falen regelmatig omdat niemand de testdata beheert, of omdat data in gedeelde, gekoppelde omgevingen steeds verandert. De oplossing is een beheerste, reproduceerbare dataset in plaats van wat er toevallig in de omgeving staat. In ons stuk over flaky tests zie je hoe vaak data de verborgen oorzaak is.
Waar haal je je testdata vandaan?
Er zijn vier gangbare bronnen, en de meeste teams hebben een mix nodig. Elke bron vraagt een afweging tussen hoe echt de data is, hoe veilig en hoeveel controle je hebt. De tabel zet ze naast elkaar.
| Bron | Sterk in | Let op |
|---|---|---|
| Een kopie van productie | Echte volumes en echte rommel. | Persoonsgegevens, omvang, trage verversing. |
| Een gemaskeerde subset | Realistisch, kleiner en veiliger. | Het maskeren moet verbanden tussen records heel laten. |
| Synthetische data | Veilig, op maat en makkelijk voor randgevallen. | Mist soms de eigenaardigheden van echte data. |
| Data die de test zelf aanmaakt | Volledige controle, geen botsingen met anderen. | Vraagt opzetcode, vaak via een API. |
Maskeren betekent dat je persoonsgegevens, zoals namen en e-mailadressen, vervangt door nepwaarden die er nog echt uitzien. Synthetische data verzin je vanaf nul, met een script of een tool. Wees voorzichtig met kopieën van productie. Persoonsgegevens in een testomgeving vallen net zo goed onder de AVG als in productie. De regels over alleen gebruiken wat je nodig hebt en privacy vanaf het ontwerp gelden daar ook. Overleg met je privacy officer voordat echte klantdata in de buurt van een testsysteem komt.
Hoe maak je testdata reproduceerbaar?
Je maakt testdata reproduceerbaar door hem te behandelen als code. Elke test krijgt data waarop hij kan rekenen, en de omgeving kan terug naar een bekende situatie. De opzet staat in versiebeheer, naast de tests. Dan start elke run, op elke dag, op dezelfde manier. Deze gewoontes maken het grootste verschil.
- Laat tests hun eigen data aanmaken. Een test die een klant nodig heeft, maakt die aan het begin aan, vaak via een API, en ruimt daarna op.
- Deel nooit testaccounts tussen tests. Moeten tests vaste records gebruiken, geef dan elke test zijn eigen.
- Zet de reset in een script. Laad voor de nachtelijke run een vaste startset, zodat restjes van gisteren niet meer uitmaken.
- Vermijd data die verloopt. Zet datums, contracten en kortingscodes relatief aan vandaag, niet vast.
- Kies de dataset per soort controle. Functionele controles hebben kleine, bekende data nodig. Controles op datakwaliteit hebben volume nodig.
Die laatste gewoonte kan veel uitmaken. In onze Data Warehouse-case draaiden de functionele tests op kleine datasets die op productie leken. De controles op datakwaliteit draaiden apart, op grote datasets. De geautomatiseerde testruns gingen van dagen naar minder dan 30 minuten, met stabiele resultaten en een makkelijkere foutanalyse.
Gekoppelde omgevingen zijn lastiger, want de data in de andere systemen heb je niet in de hand. Vervang waar het kan een systeem dat je niet beheert door een vervanger die altijd hetzelfde antwoord geeft. Martin Fowler noemt dat een test double. Kan dat niet, spreek dan met de andere teams een set testrecords af waar niemand aankomt. Bedrijfsregels controleren met API-tests helpt ook, want een API-test kan precies de data klaarzetten die hij nodig heeft.
Wat gaat er het vaakst mis?
In de meeste teams komen dezelfde paar problemen terug. Iemand anders past een gedeeld testaccount aan. Data verloopt, zoals een abonnement dat is afgelopen of een datum die nu in het verleden ligt. Een omgeving wordt zonder waarschuwing ververst vanuit productie, en alle voorbereide records zijn weg. En maar één persoon weet welke data de tests nodig hebben en waar die vandaan komt. Is die persoon op vakantie, dan kan niemand een rode run oplossen. Het onderzoek van DORA naar testdatamanagement noemt hetzelfde doel. Tests horen niet af te hangen van data die iemand met de hand moet klaarzetten.
Eén kanttekening: schone, synthetische data is prima voor geautomatiseerde controles, maar kan problemen verbergen die echte data wel laat zien. Echte klanten hebben vreemde adressen, lange namen en bestellingen met veertig regels. Houd daarom wat realistische, veilig gemaskeerde data achter de hand voor end-to-end tests over de hele keten. Geef die ook aan de mensen die exploratief testen. Iemand die in rommelige data zoekt, vindt problemen waar geen script naar kijkt.
Wat betekent dit voor je team?
Testdata is het werk dat niemand inplant. Het is geen feature, je ziet het niet in een sprintdemo, en het krijgt pas aandacht als de nachtelijke run weer rood is. Toch bepaalt het of je geautomatiseerde tests het vertrouwen waard zijn. Iemand moet eigenaar zijn van de datasets, de resetscripts werkend houden en de data bijwerken als de applicatie verandert.
Dat doorlopende werk hoort bij wat wij doen met Test Automation as a Service. Samen met je team zetten we reproduceerbare testdatasets op, naast de tests zelf. Je tests draaien elke nacht, en wij houden ze betrouwbaar. We bouwen, documenteren en onderhouden de testset en de data, zodat hij van jou blijft en niet van één persoon afhangt.
Een eerste stap voor deze week: kies de vijf tests die het vaakst falen zonder echte bug. Schrijf per test op welke data hij nodig heeft, en wie die data nog meer kan aanpassen.
Geautomatiseerde tests met data waarop ze kunnen bouwen, elke nacht.
Veelgestelde vragen
Mag je productiedata gebruiken om te testen?
Alleen met zorg. Persoonsgegevens in een testomgeving vallen onder de AVG, net als in productie. De meeste teams gebruiken daarom een gemaskeerde subset of synthetische data, en houden echte data voor zeldzame, beheerste gevallen.
Wat is het verschil tussen gemaskeerde en synthetische testdata?
Gemaskeerde data begint bij echte records en vervangt de persoonsgegevens door nepwaarden. Synthetische data is vanaf nul verzonnen. Gemaskeerde data is realistischer, synthetische data is veiliger en makkelijker te vormen.
Hoe zet je testdata terug tussen twee runs?
Laad voor elke run met een script een vaste startset, of laat elke test zijn eigen data aanmaken en opruimen. Bewaar die scripts in versiebeheer bij de tests.
Wie is eigenaar van de testdata?
Het team dat eigenaar is van de geautomatiseerde tests, met één vaste persoon die de datasets actueel houdt. Maak met andere teams afspraken over gedeelde records in gekoppelde omgevingen.