Stel je voor: maandagochtend, standup net achter de rug. De telefoon gaat. Het is de privacy officer van je organisatie. “Even een vraagje: is er productiedata in jullie testomgevingen?”
Stilte. Want het antwoord is pijnlijk duidelijk. Drie jaar geleden maakte iemand een kopie van de productiedatabase. “Tijdelijke oplossing,” zei het team toen. Sindsdien test iedereen ermee, want het werkt en niemand heeft tijd om iets beters op te zetten.
Maar die “tijdelijke oplossing” bevat echte namen, echte emailadressen en echte creditcardgegevens. En AVG-boetes gaan tot 20 miljoen euro of 4% van de jaaromzet. Dat maakt test data management ineens een stuk urgenter dan het gisteren nog voelde.
Het goede nieuws? Je hoeft geen perfect systeem neer te zetten. Dit artikel neemt je mee door zes praktische stappen waarmee je deze week al kunt beginnen, van inventarisatie tot automatisering en van privacycheck tot onderhoud. Haalbaar, pragmatisch en zonder dat je alles hoeft om te gooien.
Waarom test data management saai klinkt, maar niet kan wachten
Laten we eerlijk zijn: niemand wordt enthousiast van “laten we onze testdata eens opschonen!” En daarom stellen teams het uit. Er zijn altijd features te bouwen, altijd deadlines te halen, en testdata? Dat werkt toch?
Tot het niet meer werkt. Want slechte testdata heeft gevolgen die verder gaan dan je denkt. Allereerst is er het privacyrisico: productiedata in je testomgeving betekent echte persoonsgegevens op plekken waar ze niet horen.
Daarnaast krijg je instabiele tests (ook wel flaky tests genoemd), die soms slagen en soms falen, niet omdat er een bug is, maar omdat de onderliggende data in een onbekende staat zit. En dan heb je nog het probleem van trage tests: als je hele gigabytes aan data moet laden terwijl je maar tien records nodig hebt, duurt elke testrun onnodig lang.
Neem bijvoorbeeld een team bij een middelgroot e-commercebedrijf. Ze testten met een volledige kopie van hun productiedatabase: 40 GB aan klantgegevens, orderhistorie en productdata. Hun regressietests duurden daardoor anderhalf uur per run.
Toen ze overstapten naar synthetische data (kunstmatig gegenereerde testgegevens met alleen de records die ze echt nodig hadden) daalde die tijd naar twaalf minuten. Plus: geen privacyrisico meer.
Je hoeft dus niet te wachten tot alles perfect is. Maar beginnen, dat moet deze week. En het begint met inzicht in welke problemen er eigenlijk spelen.
De drie problemen die je waarschijnlijk herkent
Voordat je test data management kunt verbeteren, helpt het om te begrijpen waar het precies misgaat. In de praktijk zijn er drie veelvoorkomende valkuilen.
Productiedata in je testomgeving is veruit het meest voorkomende probleem. Het scenario is herkenbaar: iemand maakt een dump van de productiedatabase, laadt die in de testomgeving, en het team heeft meteen “realistische” data om mee te werken.
Maar die database bevat echte namen zoals “Jan de Vries”, echte emailadressen waarnaar je per ongeluk kunt mailen, en soms zelfs echte creditcardnummers of BSN-nummers. Dat is een AVG-schending, ongeacht of het in een testomgeving staat. Als je team ook maar een van deze rode vlaggen herkent, is er direct actie nodig.
Data-inconsistentie is het tweede grote probleem. Stel je voor: je test faalt. Je debugt een halfuur en ontdekt dat het niet aan de code ligt. Gisteren had testgebruiker X de rol “admin”, maar vandaag is dat ineens “klant” omdat een collega de data heeft aangepast.
Dit leidt tot het bekende “works on my machine” probleem: lokaal werkt alles prima, maar in de gezamenlijke testomgeving faalt dezelfde test door een andere datastaat.
Data die niet beschikbaar is klinkt misschien minder ernstig, maar het is een echte productiviteitskiller. Een tester wil aan de slag, maar heeft specifieke testaccounts nodig. “Kan iemand even een admin-account aanmaken?” En dan wacht je. Een halfuur, soms een halve dag.
De sprint goal komt in gevaar, niet door bugs, maar doordat de testdata er gewoon niet is.
Herkenbaar? Dan is het tijd om actie te ondernemen. En dat begint met een eerlijke inventarisatie van waar je team nu staat.
Waar staat je team nu? (stap 1: inventariseer)
De eerste stap is simpel maar vaak confronterend: breng in kaart hoe je testdata er nu uitziet. Waar komt het vandaan? Is het een productiekopie (hoog risico), wordt het handmatig aangemaakt door developers (tijdrovend), of wordt het gegenereerd door scripts (de gewenste situatie)?
Kijk ook naar welke data je eigenlijk nodig hebt voor je tests. Denk aan gebruikersaccounts met verschillende rollen zoals admin en klant, productcatalogi in verschillende staten zoals “op voorraad” en “uitverkocht”, transacties zoals orders en betalingen, en configuratiedata zoals feature flags en test-API-sleutels.
En dan de lastigste vraag: wie beheert de testdata nu? Bij veel teams is het eerlijke antwoord “niemand echt”. Developers maken data aan wanneer ze het nodig hebben, testers doen hetzelfde op hun eigen manier, en het resultaat is chaos. Geen eigenaarschap betekent geen consistentie.
Neem bijvoorbeeld een team van acht testers bij een fintech-startup. Toen ze deze inventarisatie deden, ontdekten ze dat vijf verschillende mensen op vijf verschillende manieren testdata aanmaakten. Twee van hen gebruikten nog steeds een productiekopie van anderhalf jaar oud. Alleen al door dit in kaart te brengen, werd het probleem zichtbaar en bespreekbaar.
Dus pak een uurtje, ga bij je team zitten, en beantwoord deze vragen samen. Het resultaat is vaak confronterender dan verwacht, maar dat is juist waarom het zo waardevol is. Zodra je weet waar je staat, is de volgende vraag: welke data is het meest risicovol?
Welke data moet het eerst worden aangepakt? (stap 2: classificeer)
Niet alle testdata is gelijk. Daarom is classificeren zo belangrijk: het helpt je om te focussen op wat het meest urgent is, in plaats van alles tegelijk te willen aanpakken.
Verdeel je testdata in vier categorieën.
Categorie A is productiedata met echte persoonsgegevens, ook wel PII genoemd (personally identifiable information, oftewel persoonlijk identificeerbare informatie): hoog risico, deze week aanpakken.
Categorie B is geanonimiseerde productiedata, waarbij de structuur bewaard is maar persoonlijke gegevens zijn vervangen: gemiddeld risico, want je moet controleren of de anonimisering compleet is.
Categorie C is synthetische data, kunstmatig gegenereerd en realistisch maar volledig fictief: laag risico, goed onderhouden en versiebeheerd.
En categorie D is minimale testdata, alleen precies wat je voor een specifieke test nodig hebt: laag risico, bij voorkeur automatisch gegenereerd.
De vuistregel is eenvoudig: alles in categorie A moet deze week worden aangepakt. Geen uitzonderingen. Want elke dag dat er echte persoonsgegevens in je testomgeving staan, is een dag dat je organisatie een AVG-risico loopt.
Maar hoe weet je zeker dat je niets over het hoofd ziet? Daar is de privacycheck voor.
Is je testdata AVG-proof? (stap 3: privacy compliance check)
Dit is de stap waar het voor veel teams oncomfortabel wordt, want het antwoord is vaker “nee” dan je zou hopen. Kijk eens kritisch naar je testdatabase. Staan er echte namen in? Echte emailadressen? Echte telefoonnummers, adressen of creditcardnummers? Als je op ook maar een van deze vragen “ja” moet antwoorden, is er direct actie nodig.
“Maar het is toch alleen de testomgeving?” hoor je regelmatig. Dat maakt voor de AVG echter niet uit. Productiedata in een testomgeving is gewoon verwerking van persoonsgegevens, en zonder geldige grondslag is dat een overtreding.
De boetes zijn niet mals: tot 20 miljoen euro of 4% van je jaaromzet. Bij een bedrijf met 50 miljoen euro omzet praat je dus over een potentiële boete van 2 miljoen euro, voor iets dat je in een week kunt oplossen.
Gelukkig zijn er snelle oplossingen. Stop vandaag nog met het maken van productiedumps naar je testomgeving. Verwijder vervolgens bestaande kopieën van productiedata uit je testdatabase (maak eerst een back-up van de structuur, niet van de persoonsgegevens).
En installeer daarna een tool zoals Faker, een gratis bibliotheek voor het genereren van nepdata die realistische maar volledig fictieve gegevens aanmaakt.
Op de middellange termijn kun je anonimiseringsscripts schrijven die namen vervangen door “Test Gebruiker 001”, emailadressen door “test001@example.com” en creditcardnummers door standaard testnummers. Daarnaast is het slim om een opschoonbeleid in te stellen: bijvoorbeeld wekelijks alle testdata verwijderen en opnieuw genereren vanuit je scripts.
En als de privacykant op orde is, kun je je focussen op het automatiseren van datageneratie. Want handmatig testdata aanmaken is niet alleen foutgevoelig, het is ook zonde van je tijd.
Stop met handmatig data aanmaken (stap 4: automatiseer)
Er zijn meerdere strategieën om testdatageneratie te automatiseren, en de beste aanpak is vaak een mix van technieken.
Seed scripts (scripts die je database vullen met testdata) zijn het meest toegankelijk. Met een bibliotheek zoals Faker genereer je in vijf minuten honderd realistische Nederlandse testgebruikers. Geen productiedata, geen privacyrisico, en volledig reproduceerbaar omdat je de scripts in versiebeheer kunt opnemen:
from faker import Faker
fake = Faker('nl_NL')
for i in range(100):
user = {
'name': fake.name(),
'email': fake.email(),
'phone': fake.phone_number(),
}
db.insert('users', user)
Dit kost je vijf minuten en levert honderd Nederlandse testgebruikers op. Faker is beschikbaar voor Python, JavaScript, Ruby en PHP, en is volledig gratis.
Database snapshots (momentopnamen van je database) zijn daarnaast ideaal voor regressietests. Je maakt een schone basislijn aan, en voor elke testrun herstel je die basislijn. Het resultaat is dat elke test begint met exact dezelfde data, dus geen instabiele tests meer door onverwachte datawijzigingen.
In-memory databases (databases die alleen in het werkgeheugen draaien, zoals H2 voor Java of SQLite in geheugenmodus) werken uitstekend voor unit tests en integratietests. Ze zijn razendsnel omdat er geen schijftoegang nodig is, en opruimen hoeft niet want de data verdwijnt automatisch na de test.
In de praktijk werkt een combinatie het best: in-memory databases voor unit tests vanwege de snelheid, seed scripts voor handmatig testen vanwege de reproduceerbaarheid, en database snapshots voor end-to-end tests vanwege de consistentie.
Maar zelfs de beste automatisering is nutteloos als niemand weet hoe het werkt. Daarom is documentatie de volgende stap.
Zorg dat je team het ook snapt (stap 5: documenteer)
Documentatie hoeft niet ingewikkeld te zijn. Een simpel bestand genaamd TEST-DATA.md in je repository is al voldoende. Beschrijf daarin waar je testdata vandaan komt, hoe je nieuwe data genereert, hoe vaak data wordt opgeschoond, en dat er geen productiedata gebruikt mag worden. Het doel is eenvoudig: een nieuw teamlid moet binnen vijf minuten begrijpen hoe testdata werkt in jullie project.
Bij een team van twintig testers bij een verzekeraar bleek dat drie mensen maandenlang hun eigen testdata-oplossingen hadden gebouwd, volledig onafhankelijk van elkaar. Toen ze een gedeeld TEST-DATA.md-bestand opzetten, bespaarden ze samen meer dan vier uur per week aan dubbel werk. Bovendien verdwenen de “works on my machine”-problemen grotendeels, omdat iedereen nu dezelfde data en dezelfde generatiescripts gebruikte.
Documentatie is er dus niet voor de bureaucratie. Het is er zodat je team sneller en consistenter kan werken. En de laatste stap? Ervoor zorgen dat het ook zo blijft.
Houd je testdata gezond (stap 6: monitor en onderhoud)
Test data management is geen eenmalig project maar doorlopend onderhoud, vergelijkbaar met het bijhouden van je codebase. Daarom is het belangrijk om een paar gezondheidsmetrieken bij te houden.
Let op het datavolume: als je testdatabase ongecontroleerd groeit richting tientallen gigabytes, is het tijd om op te schonen. Houd ook de generatietijd in de gaten, want als het langer dan vijf minuten duurt om testdata aan te maken, is er ruimte voor verbetering.
En check regelmatig of er toch geen persoonsgegevens in je testdata zijn beland. Dat laatste klinkt misschien overdreven, maar het is makkelijker dan je denkt om per ongeluk een productie-export te draaien.
Stel een eenvoudige routine in: wekelijks testdata opschonen en privacycompliance checken, maandelijks je generatiescripts reviewen of ze nog actueel zijn, en elk kwartaal een volledige audit doen. Wijs ook een eigenaar aan, iemand die verantwoordelijk is voor de testdata. Want als niemand eigenaar is, voelt ook niemand zich aangesproken als het misgaat.
En eerlijk? Die eigenaar hoeft geen fulltime rol te zijn. Eén persoon die wekelijks een kwartiertje besteedt aan een snelle check maakt al een wereld van verschil.
Maar welke tools maken dit werk nu echt makkelijker? Dat hangt af van de grootte van je team.
Welke tools passen bij jouw team?
Voor kleine teams tot tien personen is de combinatie van Faker en Mockaroo (een online testdatagenerator met een visuele interface) ruim voldoende. Beide zijn gratis voor de meeste toepassingen en de leercurve is laag: binnen vijf minuten genereer je je eerste dataset.
Middelgrote teams van tien tot vijftig personen doen er goed aan om naast Faker ook Docker-snapshots en seed scripts in te zetten. De extra kosten zijn minimaal, misschien zestig euro per jaar voor een Mockaroo premium-account, maar de tijdsbesparing is aanzienlijk.
Grote organisaties met meer dan vijftig personen kunnen kijken naar enterprise-tools zoals Delphix of IBM Optim voor data masking (het automatisch vervangen van gevoelige gegevens in databases). Deze kosten tienduizenden euro’s per jaar, maar voor organisaties in sterk gereguleerde sectoren zoals financiën of zorg kan dat een goede investering zijn.
De vuistregel is simpel: begin klein en schaal op wanneer dat nodig blijkt.
Wat je morgen anders kunt doen
Je hoeft niet alles tegelijk aan te pakken. Test data management is geen big-bangproject, het is een reeks kleine, haalbare stappen.
Deze week: stop met productiedumps naar je testomgeving, installeer Faker, en genereer je eerste honderd synthetische testgebruikers. Verwijder daarna de productiedata uit je testdatabase. Dat kost je een middag en het neemt direct het grootste privacyrisico weg.
Deze maand: schrijf seed scripts voor al je belangrijkste datasets, maak een TEST-DATA.md aan in je repository, en stel een wekelijkse opschoonroutine in.
Dit kwartaal: doe een volledige audit, wijs een eigenaar aan, en evalueer of je huidige aanpak nog past bij de groei van je team en product.
Het belangrijkste inzicht? Test data management is niet moeilijk. Het is alleen makkelijk om uit te stellen. En elke week dat je het uitstelt, is een week dat je team test met data die privacyrisico’s met zich meebrengt, tests instabiel maakt en testers onnodig laat wachten.
Begin vandaag, met een klein eerste stapje, en bouw van daaruit verder.
Wil je sparren over hoe test data management er voor jouw team uit kan zien? Of loop je tegen specifieke uitdagingen aan? We denken graag (geheel vrijblijvend) met je mee.. Plan een gesprek
Meer lezen over testplanning
- Test coverage: hoeveel procent is genoeg? – framework voor je coveragedoel
- Smoke test vs sanity test – wanneer welke gebruiken
