Review this setup. A nightly masked clone of production feeds three shared environments, a subsetting tool builds per-team slices on request through a ticket queue with a two-day turnaround, and a synthetic generator covers new features. What would you remove, and what is the one change that matters?

What is actually required

One property, and the setup does not provide it: a test must be able to create the exact data it needs, by itself, in seconds, without affecting anyone else's test. Everything else in test data management is a supporting act.

What I would remove, and why it is safe to

• The ticket queue. A two-day turnaround converts a data need into a scheduling problem, so engineers write tests against whatever data already exists. That is how suites acquire hidden coupling to a shared fixture that nobody may change, and it is the root of most "works for me" arguments. Removing it is safe because the demand it serves is better met by self-service creation.
• Shared data in the shared environments. Three environments sharing one dataset means every test is a neighbour of every other. Replace with per-test tenancy: each test creates its own tenant or account through the product's own APIs and deletes it at the end.
• Synthetic data as a general-purpose source. Keep it where it is genuinely good — volume for performance work, and fabricating edge cases that production does not contain — and stop treating it as a substitute for realistic shape. A generator that produces only valid records removes exactly the malformed, duplicated and historically odd rows that find bugs. A marketplace with twenty years of history, in the mould of eBay, has record shapes no generator will invent.

The one change that matters

Test-owned data creation through the product's own write path, with factories in the test code and isolation by tenant. It makes tests independent, self-documenting about their preconditions, and runnable in parallel. It also exercises the creation path, so a broken onboarding flow fails a thousand tests rather than hiding behind a seeded database.

What I would leave, even though it looks odd

• The masked production clone. It has a real job: volume, cardinality and distribution for performance and migration rehearsal, which no generator reproduces. Keep it, size it honestly, and stop using it as the source of functional test data.
• A small curated golden dataset for the two or three legacy flows whose setup genuinely cannot be created through an API. Naming them as exceptions is better than pretending they do not exist.

How I would argue this in the review

Not on principle. Bring the numbers: how many tickets the queue served last quarter, the median wait, how many tests were skipped or disabled while waiting, and how many defects the shared data caused as measured by reruns. Then note the risk nobody has priced: masked is not anonymous. Masking that preserves referential integrity and format usually preserves re-identification too, so those environments still hold personal data and inherit its access controls, retention and breach obligations. That reframes the clone from a convenience into a liability with a budget, which is the argument that actually moves a decision.

When not to touch any of it

If the whole estate is one team, one environment and 20 minutes of tests, this machinery is already too much and a seeded fixture plus a reset script costs almost nothing. The setup above is a response to scale, and the parts worth keeping are the ones that still pay at scale: volume data for performance work, and isolation per test. Prefer removing the queue over adding a tool to make the queue faster, because the queue's cost is the two days of waiting rather than the minutes of work inside it.