Synthetic test data
Synthetic test data is data generated to a schema and a set of rules rather than copied from real records, so that a test environment holds accounts, orders and events that look and behave like production data without any of them belonging to a real person. It is one of the three sources of test data, and the one that removes the privacy problem instead of masking it.
The longer version
Generation starts from what the data has to satisfy: the schema, the constraints between tables, the distributions that matter (most orders have one line, a few have forty) and the rules of the domain (a refund cannot exceed its order). A generator, from a seeded script to a purpose-built tool, produces records that meet those rules in whatever volume the test needs. Because nothing was copied, the output carries nobody's personal data and can be handed to a contractor, loaded on a laptop or shown in a demo, and it can be regenerated from a fixed seed so that two runs see the same records.
The alternative is a masked copy of production, and the trade-off is coverage against safety. A masked copy contains every strange record that real customers created, and the masking has to be checked for leaks. Synthetic data contains only the strangeness somebody thought to specify, and leaks nothing, provided the generator is driven by rules: a generator trained on production records can reproduce them, and its output needs the same leak check as a masked copy. Synthetic data is one of the sources test data management chooses among, and most teams pair it with another.
Generated names, addresses and amounts look right and hit none of the cases that matter: no surname with an apostrophe, no address in a country without postcodes, no order whose total is exactly zero, no account created before the schema change that introduced a required column. Tests pass against a population with none of the records that caused the last production incident. Good synthetic data is deliberately ugly: the generator is fed the edge cases from the incident log and the boundary values from test design, so that the awkward records exist on purpose.
Common questions
What is the difference between synthetic test data and masked production data?
Masked production data is a real extract with the personal fields replaced; it keeps every awkward record real users created and has to be checked for leaks. Synthetic data is generated from the schema and rules and contains nothing real, so it is safe by construction and only as awkward as its generator was told to be.
When should a team use synthetic test data?
When production data cannot leave production, when the environment is shared with people who should not see real records, when a test needs volume that production does not have, or when a case needs a record no real customer has created yet. Teams also use it to seed a fresh environment quickly, then add masked extracts for the realism a generator misses.
Is synthetic test data realistic enough for testing?
Realistic enough for the cases it was generated to cover, and no further. A generator produces the distribution it was given, so the awkward records real data contains, unusual names, empty totals, accounts older than the schema, exist only if somebody specified them. Feeding the generator the edge cases from past incidents is what closes the gap.
How is synthetic test data generated?
From the schema, the constraints between tables and the rules of the domain, fed to a generator that ranges from a seeded script to a purpose-built tool. The generator is told the distributions that matter and the awkward records it must include, and it runs from a fixed seed so two runs produce identical data. Nothing is copied from real records, which is what makes the output safe to share.
Is synthetic test data safe under privacy rules?
Synthetic data generated from a schema and rules contains nobody's records, so it can be loaded on a laptop, shown in a demo or handed to a contractor without the obligations a production copy carries. The exception is a generator trained on real records, which can reproduce them and whose output needs the same leak check as a masked extract before it is treated as safe.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.