I have been a test manager for nineteen years, most of it in pensions, a mortgage servicer and the Dutch immigration service. The recurring problem in all of them was never the test cases. It was the data: personal data that could not be copied from production, and made-up data that failed the first validation it met.
A good part of ToolForte exists because of that problem. This post is how I use it on a test project, in the order the project needs it.
Week one: data that passes the checks and is nobody
A Dutch system checks a BSN (the citizen service number) with the elfproef (a weighted checksum), and an IBAN with mod-97. Random digits fail both. Real numbers are personal data and may not be used. The test BSN generator and the test IBAN generator produce numbers that pass the arithmetic and are generated for testing rather than copied from anyone; each page says how it makes them.
When the system needs whole people rather than numbers, the BRP test data generator makes synthetic persons in the shape of the BRP (the Dutch population register): names with tussenvoegsels (the "van" or "de" in a surname), addresses with real postcode formats, birth dates in a range you set, and relations where you ask for them. For pension work the UPA file generator builds a UPA (the Dutch pension data declaration) with the scheme rows and periods you specify, so the intake process has something realistic to chew on.
Pin the seed, then stop touching it
Both generators take a seed. The same seed returns the same data, every time, on the tool page, over the API and over MCP. This is the single most useful property they have. Write the seed in the test plan. When SIT (system integration testing) finds a defect on person 37 and UAT (user acceptance testing) wants to reproduce it, everyone generates from the same seed and gets the same person 37.
I put the seed in the run's name: sit-wave2-seed-20260915. A colleague who sees that name can regenerate the whole batch without asking me.
Both generators take a seed.
Defect triage: is the data wrong or is the system wrong
Half of the defects raised in a data-heavy project are the test data's fault. The validators settle that in a minute. A payment that failed: paste the IBAN into the IBAN validator; if it reports a bad checksum, the defect is in the data, close it. A rejected record: the JSON formatter on the API response, then the diff checker against the same record from yesterday, shows which field moved.
None of this uploads anything. The records stay in the tester's browser, which is the condition under which a client lets you paste them at all.
The same run, the same way, over the API
Once the data shape is agreed, nobody should be clicking a generator. A seed script calls POST /api/v1/tools/brp-test-data-generator with the seed and the record count, and POST /api/v1/tools/test-iban-generator for the accounts, and loads the result into the test database before every wave. One credit per call; a wave of two hundred persons is two calls, because the generator returns a batch. The API post has the details, and the generator reference documents every option with its type, range and default.
A workflow does the same for the person who is not a developer: a saved chain that generates the batch, validates a sample, and formats the output, run from one form with the seed as its only input. The workflows post shows how to build one.
Once the data shape is agreed, nobody should be clicking a generator.
What I still do by hand
Edge cases. The generator makes plausible people; a test plan also needs the implausible ones, the 106-year-old, the person with no address, the IBAN from a country the system has never seen. I build those by hand from the generator's output, and I write down why each one exists.
And the sign-off. A tool tells you the data is valid. It does not tell you the data covers the risk. That is the test manager's job, and the tools only make more time for it.
Images by Pexels
HTTP Security Headers Checklist: Six Headers and How to Set Them
The six HTTP security headers that stop XSS, clickjacking and HTTPS downgrades, with copy-and-paste configs for Vercel, Nginx, Apache and Cloudflare, and how I check them.
What Shadow DOM Isolates in a Web Component, and What Leaks Through
Custom elements and Shadow DOM without the hype. Which styles, selectors and events cross the shadow boundary, how theming works, and the testing and accessibility traps I keep running into.
Dutch Test Data from a Script: The BRP and UPA Generators over API and MCP
Generate BRP persons and UPA pension declarations from your test suite, your seed script or your AI assistant. Every setting on the tool page is a field in the request, the same seed always returns the same data, and a call costs one credit.
Dutch Test Data That Passes Validation Without Being Anyone: BSNs, IBANs and BRP Records
Every Dutch administration system checks the BSN and the IBAN before it stores them, and the AVG has no exception for test environments. How I generate data that passes the elfproef and the mod-97 check and belongs to nobody, by hand, by API and from an AI agent.