Lesson 5 of 5
Synthetic versus copied data
9 min
Listen to this lesson
There are two broad ways to fill a test system. You can create synthetic data: new business partners, products and documents built for the test. Or you can copy production data, in full or as a slice. Neither is always right. Mature programs use both, chosen per test purpose.
Ways to create synthetic data
- Manual entry through the normal apps. Fine for a handful of records; slow and error-prone for hundreds.
- Migration tooling. The SAP S/4HANA migration cockpit (the Migrate Your Data app) loads business partners, products, open items and stock from templates. Reusing migration templates for test data also tests the migration objects.
- APIs. Released OData and SOAP APIs, documented on the SAP Business Accelerator Hub, can create business partners, products and documents in a repeatable way, which suits automated setup steps.
- Process execution. Running the upstream process, such as creating and receiving a purchase order, is the most realistic way to create transactional data and stock.
Ways to copy production data
A full system copy gives the most realistic picture but is large, slow to refresh, and brings all the privacy obligations from the previous lesson. Selective copies, made with tools such as SAP Test Data Migration Server, transfer a time slice or a subset of company codes with master data, which keeps systems smaller. Either way, scrambling and access control come first.
| Factor | Synthetic data | Copied production data |
|---|---|---|
| Privacy risk | Low: no real people | High until scrambled |
| Realism and variety | Only what you thought of | Real edge cases, history and volumes |
| Control and repeatability | High: known values, recreated on demand | Low: values change with each refresh |
| Effort | Upfront design and scripts | Refresh runbook, scrambling, post-copy steps |
| New processes and new org units | Works: data can be built for them | Does not work: production has no such data |
| Best for | Functional, regression, automated tests | Performance, migration rehearsal, edge-case discovery |
A decision guide
- Does the test cover something production does not have yet (new process, plant, document type)?Yes → synthetic data · No → next question
- Does the test need exact, repeatable values (automated regression, expected results)?Yes → synthetic data created by script or API · No → next question
- Does the test need realistic volume or variety (performance, migration rehearsal, data quality)?Yes → scrambled production copy or slice · No → next question
- Does it involve personal data features (blocking, deletion, consent)?Yes → synthetic people built for the purpose · No → either, choose the cheaper to maintain
Keeping synthetic data maintainable
Synthetic data only pays off if it can be rebuilt quickly. Keep the definitions, not just the records: a migration template, an API script or a setup test that creates Contoso's test customers, products, prices and opening stock from scratch. Version those definitions alongside the test cases. When a refresh wipes QAS, or configuration changes add a mandatory field, you update the definition once and rebuild, instead of repairing hundreds of records by hand.
Give synthetic records recognizable keys or search terms, for example a prefix in the business partner search term, so nobody mistakes them for real data and so cleanup jobs can find them. And keep synthetic data realistic enough to exercise the rules: a customer without a tax classification or a product without a weight will not test tax determination or freight.
What would you do?
Dan, Contoso's finance process owner, asks for the automated regression of the period-end close to run on the latest production copy "because that's the real data". The regression compares results with stored expected values. What do you recommend?
- Synthetic data is safe, controllable and repeatable, and it is the only option for new processes and org units.
- Copied production data brings realism, volume and real edge cases, but needs scrambling and refresh discipline.
- Choose per test purpose: regression and automation favor synthetic data; performance and migration rehearsal favor scrambled copies.
- Check that the data behind a key result supports the claim you are signing off.
Check your understanding · not graded
Lesson check
1. Contoso tests a brand-new plant that has no production history. Which data source fits?
2. Which SAP S/4HANA app loads business partners, products and open items from templates?
3. Why does automated regression usually prefer synthetic data?
4. Which test most benefits from a scrambled production slice?