Building an SAP Testing CoE · Part 5
Test data for S/4HANA: copies, masking and synthetic data
Most broken SAP tests are broken by data. Compare full copies, subsets, masking and synthetic data, and set up a client strategy your CoE can actually run.
Matt Angerer
October 8, 2026 · 9 min read
Ask any SAP test lead why last night’s run failed and the answer is usually data. The customer was blocked, the material had no stock, the purchase order was already received by another test, the client was refreshed. Test data is the least glamorous part of a Testing CoE and the one that decides whether everything else works.
Four ways to get test data
| Approach | Strengths | Watch out for |
|---|---|---|
| Full system copy | Realistic data and volumes; simple to explain. | Huge storage and refresh time; production personal data in a test system unless masked. |
| Client or time-slice subset | Smaller and faster to refresh; keeps real relationships between documents. | Needs specialist tooling and care to keep data consistent across modules. |
| Masked copy or subset | Realistic structure with personal data scrambled; supports privacy obligations. | Masking must stay consistent across tables and interfaces or tests break. |
| Synthetic data | No personal data at all; created on demand for exactly the scenario under test. | Needs upfront work to generate valid SAP master data and the documents that depend on it. |
Most mature CoEs combine them: a masked, reduced copy as the foundation for integration and UAT, and synthetic or test-created data for automated regression, so each test controls its own starting point.
Make data a property of the test
The single biggest improvement you can make is to stop tests relying on data that happens to exist. Three patterns, from simplest to most robust:
- Create what you need. The test creates its own customer, material and stock as setup steps, ideally through APIs or BAPIs so setup is fast.
- Reserve from a pool. A managed pool of valid records that tests check out and release, so two tests never consume the same open item.
- Find by criteria. The test queries for a record that matches what it needs (a released material with stock in plant 1000, for example) rather than using a hard-coded number.
Migration data is test data too
On an S/4HANA migration, the data being migrated is itself under test. Every mock load needs reconciliation: record counts, financial balances by company code and period, open items, stock quantities and values. Automate these reconciliations early. You will run them for every mock, the dress rehearsal and the real cutover, at 3 a.m., under pressure.
A client strategy you can run
Write down which client is for what, who can change it and how it is refreshed. A common pattern:
- Development: configuration and unit testing, minimal data.
- Quality (QAS): integration and automated regression, refreshed from a masked copy on a fixed schedule.
- Pre-production: UAT, performance and cutover rehearsals, closest to production in data and size.
Test data health check
- Every client has a documented purpose, owner and refresh schedule
- Personal data is masked or absent outside production
- Automated tests create, reserve or query their own data
- Refreshes are followed by an automated smoke test
- Migration reconciliations are scripted and repeatable
Key takeaways
- Data, not code, breaks most SAP tests.
- Combine a masked, reduced copy for people with test-created or synthetic data for automation.
- Make each test responsible for its own data.
- Automate migration reconciliation early; you will run it many times.
That completes the core series. Start from the beginning with the SAP Testing CoE playbook, or see how AI-DLC changes the lifecycle around all of this.