29 Oct 2026 Test data management: how to give automated tests data they can trust

In short: Test data management means planning, creating, protecting and resetting the data your tests use. For automated tests, the goal is simple: every run starts from a known state. That means tests that create or claim their own data, reset scripts you keep with your tests, and care with real personal data. Without it, tests fail for reasons that have nothing to do with your code.

A test passed yesterday and fails today, and nobody changed the code. Then someone finds out why. A colleague used the same test customer and changed the address. Or the discount code in the test expired last night. Problems like these eat hours every week, and they slowly make people stop trusting the test results. Good test data management stops most of them before they start.

What is test data management?

Test data management is the work of planning, creating, protecting and resetting the data your tests use. Test data is everything a test needs to exist before it starts. Think of customers, products, orders, accounts and settings. For manual testing, loose data is annoying but workable. A tester who finds the test customer gone just picks another one. An automated test can’t do that. It expects exactly the data it was written for, and fails when that data has changed. So the goal for automation is that every run starts from a known state. At e-commerce clients we see this often. Automated tests fail regularly because nobody manages the test data, or because data in shared, linked environments keeps changing. The fix is controlled, reproducible datasets instead of whatever happens to be in the environment. Our post on flaky tests shows how often data is the hidden cause.

Where should your test data come from?

There are four common sources, and most teams need a mix. Each has its own trade-off between how real the data is, how safe it is and how much control you have. The table compares them.

Masking means you replace personal details, such as names and email addresses, with fake values that still look real. Synthetic data is made up from scratch, by a script or a tool. Be careful with copies of production. In the EU, personal data in a test environment falls under the GDPR just as it does in production. The rules on using only the data you need and protecting it by design apply there too. Check with your privacy officer before real customer data goes anywhere near a test system.

How do you make test data reproducible?

You make test data reproducible by treating it like code. Each test gets data it can rely on, and the environment can be reset to a known state. The setup lives in version control next to the tests. Then any run, on any day, starts the same way. These habits make the biggest difference.

1. Let tests create their own data. A test that needs a customer creates one at the start, often through an API call, and cleans up after itself.
2. Never share test accounts between tests. If tests must use fixed records, give each test its own.
3. Script the reset. Load a fixed starting dataset before the nightly run, so yesterday’s leftovers don’t matter.
4. Avoid data that expires. Dates, contracts and discount codes should be set relative to today, not fixed.
5. Pick the dataset per type of check. Functional checks need small, known data. Data quality checks need volume.

That last habit can change a lot. In our Data Warehouse case, functional tests ran on small, production-like datasets. The checks on data quality ran on their own, on big datasets. Automated test runs went from days to under 30 minutes, with stable results and easier root-cause analysis.

Linked environments are harder, because you don’t control the data in the other systems. Where you can, replace a system you don’t control with a stand-in that always gives the same answer. Martin Fowler calls these test doubles. Where you can’t, agree with the other teams on a set of test records that nobody touches. Checking business rules through API tests also helps, since an API test can set up exactly the data it needs.

What goes wrong most often?

The same few problems come back in most teams. A shared test account gets changed by someone else. Data expires, such as a subscription that ended or a date that is now in the past. An environment gets refreshed from production without warning, and every prepared record is gone. And only one person knows which data the tests need and where it comes from. When that person is on holiday, nobody can fix a red run. DORA’s research on test data management names the same goal: tests should not depend on data that someone has to prepare by hand.

One trade-off to name: clean, synthetic data is great for automated checks, but it can hide problems real data would show. Real customers have odd addresses, long names and orders with forty lines. So keep some realistic, safely masked data for end-to-end tests across the whole chain. And give it to the people doing exploratory testing too. A person poking at messy data finds problems no script would look for.

What this means for your team

Test data is the work nobody plans. It isn’t a feature, it doesn’t show up in a sprint demo, and it only gets attention when the nightly run is red again. Yet it decides whether your automated tests are worth trusting. Someone has to own the datasets, keep the reset scripts working and update the data when the application changes.

That ongoing work is part of what we do with Test Automation as a Service. Together with your team, we set up reproducible test datasets next to the tests themselves. Your tests run every night, and we keep them reliable. We build, document and maintain the suite and its data, so it stays your asset and doesn’t depend on one person.

A first step you can take this week: pick the five tests that fail most often without a real bug. For each one, write down which data it needs, and who else can change that data.

Frequently asked questions

Can you use production data for testing?

Only with care. Personal data in a test environment falls under the GDPR, just like in production. Most teams use a masked subset or synthetic data instead, and keep real data for rare, controlled cases.

What is the difference between masked and synthetic test data?

Masked data starts from real records and replaces personal details with fake ones. Synthetic data is made up from scratch. Masked data is more realistic, while synthetic data is safer and easier to shape.

How do you reset test data between runs?

Load a fixed starting dataset with a script before each run, or let every test create and clean up its own data. Keep those scripts in version control with the tests.

Who should own test data?

The team that owns the automated tests, with one named person who keeps the datasets current. Agree with other teams on shared records in linked environments.