Synthetic Test Data: How and When to Use It - Blog

Synthetic test data is artificial data generated to look and behave like production data without being copied from real records. Teams use it to test software where real data is sensitive, scarce or does not exist yet. Good synthetic test data respects the schema, business rules and relationships between tables, and it deliberately includes the edge cases that production data rarely shows.

What synthetic test data is

Test data comes from three sources: copies of production, masked copies of production, and generated data. Synthetic test data is the third. It can be as simple as a script that inserts 1,000 customers with fake names, or as complex as a full ERP dataset with consistent orders, deliveries, invoices and payments generated from statistical models of the real system.

When no record corresponds to a real person, well-built synthetic data generally falls outside data protection law. "Well-built" matters. Generating it from real records is itself processing of personal data, and synthetic data modeled closely on real records can still reveal individuals, especially unusual ones, if the generation method memorizes them.

Rule-based vs model-based generation

Rule-based generation

Rule-based generators produce values from explicit definitions: patterns, ranges, lists, sequences and formulas. A rule might generate account numbers matching [A-Z]{2}[0-9]{8}, ages between 18 and 90, or an order status picked from a fixed list with given weights. The values are created independently of any original data.

Strengths: fully controllable, no dependency on real data, and easy to aim at specific scenarios.
Weaknesses: distributions and correlations are only as realistic as the rules, and complex schemas need a lot of rules.

Model-based generation

Model-based generators fit a model to existing data and sample new values from it. They reproduce distributions, category frequencies and correlations between columns, for example that order values cluster by region or that certain products are bought together.

Strengths: realistic shapes and volumes, which suits performance, analytics and reporting tests.
Weaknesses: needs access to source data, must be checked for privacy leakage, and tends to reproduce common cases rather than the rare ones you most need to test.

Most real projects combine both: models for realistic bulk data, rules for fields with strict formats and for scenarios you need to force.

Synthetic data vs masked production data

Neither approach wins everywhere. A practical split:

Use masked production data for regression, UAT, migration and integration testing, where you need the real variety of historical records, configuration and messy data quality.
Use synthetic data for new features with no production data yet, performance tests that need more volume than production holds, demos and training, sharing with external parties, and scenarios that production does not contain.
Combine them by masking a subset of production and adding synthetic records to fill the gaps.

The choice can also be made per table or per column: mask the transaction history, generate the customers, keep the reference data.

Keeping referential integrity

Synthetic data that breaks relationships is worse than no data: tests fail on missing parent records, and defects get raised against healthy code. Generation needs to:

Generate parent tables first, and draw every child foreign key from parent keys that were actually generated.
Respect cardinalities, such as one to five addresses per customer, not one to five thousand.
Honor relationships that exist only in application logic, not in database constraints. These need to be declared to the generator, often as virtual foreign keys.
Keep cross-column rules: delivery date after order date, totals equal to the sum of line items, country consistent with postal code.
Stay consistent across files and systems, for example the same customer ID in a CSV extract, a database table and an API payload.

Designing for edge cases

Production data is dominated by the happy path. Synthetic data lets you put the unusual cases in on purpose, as described in balancing happy path and negative testing:

boundary values: zero, negative amounts, maximum field lengths, leap days, period-end dates;
invalid and incomplete records: missing addresses, duplicate customers, expired cards;
rare business states: partial deliveries, reversed invoices, disputed payments;
internationalization: non-Latin names, long addresses, multiple currencies;
volume extremes: a single customer with 50,000 orders.

Generate these as named, repeatable scenarios rather than random noise, so a failing test can be rerun against exactly the same data.

Synthetic test data for AI agents

AI agents that read tickets, look up accounts and update records need more than rows in a table. They need a consistent world: a customer whose database record, emails, chat history and attached statement all agree, plus deliberate conflicts to test judgment. Useful scenarios include a document that contradicts the database, a missing record, an access restriction, and an instruction aimed at the agent hidden inside an email or PDF. Replaying production conversations instead copies personal data into prompts, logs and traces. Our page on test data for AI agents goes further.

Reproducibility matters even more for agents than for deterministic code. The same configuration and seed should rebuild the same customers, so each new agent version runs against the same scenario suite.

Synthetic documents

Document processing, OCR, extraction and PII detection all need sample files: bank statements, pay stubs, lab reports, invoices, claim forms. Real ones carry personal data, and blank templates do not exercise extraction. Synthetic documents fill the gap when they:

are rendered from generated values, so names, addresses and accounts agree across every document about one person;
come with the true values as structured data, so extraction can be scored field by field;
include clean, scanned and fax-quality variants to test OCR.

How to get started with synthetic test data

Start small and tie the work to a test suite that is blocked today:

Pick one suite that fails or waits because of data access, missing scenarios or data that keeps getting consumed.
List the entities and states it needs: customers, accounts, open orders, failed payments, a blocked user.
Decide per table whether to generate, mask from production or keep reference data as it is.
Write rules for strict-format fields and forced scenarios, and use model-based generation where you need realistic bulk.
Validate joins, constraints and business rules, then version the configuration so the same dataset can be rebuilt on demand in CI.

How Synthesized helps

Synthesized generates synthetic data alongside masking and subsetting in its test data management platform. Generators range from rule-based ones, such as formatted strings and sequences, to ones that fit a model to existing data and follow its distributions, while foreign keys, including virtual ones, stay valid. Linked CSV sets and schema-valid XML generated from an XSD are also supported. Test Data Agent builds PII-free data and system states with happy-path, exception and adversarial scenarios to validate AI agents. Free sample documents include synthetic bank statements, pay stubs and lab reports with their true values.

FAQ

What is synthetic test data?

Synthetic test data is artificially generated data that mimics the structure, formats and statistical patterns of production data without copying real records. Teams use it to test applications where real data is sensitive, unavailable or insufficient, for example new features, performance testing at higher volumes, demos, and edge cases that production data rarely contains.

Is synthetic test data better than masked production data?

It depends on the test. Masked production data keeps the real variety, history and data quality issues that regression, migration and UAT testing need. Synthetic data is better for new features, volume, edge cases and sharing outside the organization. Many teams use both: a masked subset of production plus synthetic records for the scenarios it lacks.

Is synthetic data covered by GDPR?

Synthetic data that is generated rather than copied, and does not reproduce real individuals, is generally outside GDPR. Two caveats apply. Generating it from real records is itself processing of personal data, and a model that memorizes unusual records can leak them into the output. Check the generation method before treating synthetic data as anonymous.

How do you keep referential integrity in synthetic data?

Generate parent tables before child tables and draw every foreign key from keys that were actually generated. Declare relationships that exist only in application code so the generator respects them, keep cross-column rules such as date order and totals, and validate the output with joins that should return complete chains. Broken keys cause false test failures.

Synthetic Test Data: How to Generate It and When to Use It