Test data management
Test data management is the practice of provisioning, protecting, refreshing and retiring the data that tests run against, so that every environment holds records of the right shape when a test needs them and no real customer data ends up somewhere it should not be. It covers where the data comes from, who can see it, how it is reset and how long it lives.
The longer version
The problem it solves is that tests need data that does not exist by accident. A staging environment starts empty; a test that needs a customer with an overdue invoice needs somebody to have created one. Multiply that by every environment, every team and every case, and the creation has to be organised: a source the data comes from, a process that loads it, a policy about what it may contain, and a reset that returns the environment to a known state after a run has changed it. Test data management names that organisation, whether it is a script and a spreadsheet or a dedicated system.
The three sources are hand-authored data, a masked subset of production, and synthetic data generated to a schema. Hand-authored data is exact and thin. A masked copy has the shape of reality, including the awkward records, but it has to be anonymised well enough that no customer can be recognised, and masking that preserves the links between tables is where most of the effort goes. Synthetic data avoids the privacy problem and has to be told about the awkward records explicitly. Test environment management is the adjacent practice, concerned with the machines rather than the records, and the two are usually owned by the same people.
Unmanaged test data blocks releases under other names. A release is blocked because staging has no order in the state the acceptance test needs, and the team spends the afternoon building one by hand. A test passes on Monday and fails on Wednesday because another team's run consumed the shared record. Worst, a production extract copied to a test server with a shared password turns a testing shortcut into a data breach. Each of those is a data process failure that gets logged as a flaky test or an environment problem.
Common questions
What does test data management include?
Sourcing the data, from hand-written values, a masked production copy or a synthetic generator; loading it into each environment; masking anything personal; resetting environments after runs have changed them; refreshing sets that have gone stale; and retiring data that is no longer needed. The policy about what may be loaded where is part of it, since that is what keeps real customer data out of a test server.
What is the difference between test data management and test environment management?
Environment management is about the machines: which build is deployed where, which versions, which configuration, who has access. Test data management is about the records those machines hold. A test can be blocked by either, and the two practices are usually owned together because an environment reset and a data reset happen at the same time.
Can production data be used as test data?
Only after masking, and only where the masking has been checked. A copy of production carries every privacy obligation of the original into an environment with weaker access controls, so the personal fields are replaced before it leaves production, and the links between records are preserved so the copy still behaves like real data. Where masking cannot be verified, synthetic data is the safer source.
Who is responsible for test data management?
Whoever owns the shared environments, which on a small team is the tester who loads the set and on a larger one a test data owner or the environment team. The responsibility covers the policy about what may be loaded where, not only the loading, because the person who decides that a production extract can be copied is the one accountable when it leaks.
Can test data management be automated?
Most of the mechanics can: generating synthetic records from a schema, masking a production extract with a fixed rule set, loading a set into an environment and resetting it after a run. What does not automate is the policy, which records must exist for which cases and what may never leave production, and an automated pipeline that loads the wrong thing does so faster.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.