SAP test data for S/4HANA: five ways compared

Five ways to get SAP test data at a glance

Good test data uncovers errors before they occur in production, without creating new risks. Five criteria are decisive: How much effort does provisioning take? How meaningful are the tests, i.e. how close to production, with edge cases and complete document chains? How much main memory does the data occupy in SAP HANA? How much personal data ends up in the test system? And how up to date does the data stay?

Approach	Effort	Realism	HANA memory	Data protection	Freshness
System copy	High: the entire target system is overwritten, extensive post-processing	Maximum: all data, all edge cases, real volumes	As in production	All personal data in plain text unless it is masked	As of the copy; refreshes are rare because they are laborious
Client copy (standard)	Medium to high: runtime grows with the history, plus follow-up tasks	High: complete history of the client with all document chains	Close to production sizing	As with the system copy, for the copied client	As of the copy; outdated until the next refresh
Partial copy by time slice	Tool and setup required, repeatable afterwards	High for the time frame, provided all dependent objects are included	Only the time frame plus dependencies	Less personal data, masking still required	More frequent refreshes possible because smaller and faster
Created manually or by test automation	High per test case, maintenance with every process change	Exactly the planned cases, no unknown edge cases	Low	Uncritical as long as no real data is used	Can be recreated at any time, independent of production
Synthetically generated	High: rules or a model for the SAP data model have to be built	As good as the model, volumes scale well	Freely selectable	Favourable; if derived from production data, check whether it allows inferences about real people	Independent of production; the model has to be kept up to date

Simplified classification. In individual cases, the assessment depends on system size, tools and test objectives.

Full copies: system copy and client copy

A system copy transfers the entire database: all clients, the repository and the cross-client data. The target system is then an image of production, including the development status. How it works is described in the article SAP system copy: methods, procedure and post-processing.

The standard client copy transfers the client-specific data of one client. With the profile SAP_ALL, Customizing, application data and user master records are included. The copy profiles select types of data, but not a time frame.

Both deliver the maximum of reality: real document chains across modules, master data that has grown over time, and edge cases that nobody thought of when designing the test cases. That is why they are popular for integration and acceptance tests. The price shows in three places:

Memory: SAP HANA keeps the data in main memory. Every full copy needs almost as much RAM as production, and RAM is currently becoming considerably more expensive.
Time: Copy, BDLS run, interfaces, jobs and users. On large systems, a refresh quickly becomes a weekend project.
Data protection: Every full copy brings all the personal data from production into a system in which more people usually work with broader authorisations.

In its IT-Grundschutz, the German Federal Office for Information Security (BSI) explicitly lists tests with production data as a threat. If the test data contains personal information, module OPS.1.1.6 sets out as a basic requirement that it must at least be pseudonymised. More on this in the article Personal data in SAP test systems. What main memory costs is shown in the article RAM prices and S/4HANA.

System copy

Overwrites the entire database

Client copy

Overwrites one client with its full history

Time-slice client copy

Overwrites one client with a time period, e.g. 90 days, plus dependent objects

A system copy replaces everything, a client copy one client with its entire history, a time slice only the period you need. Schematic diagram.

Partial copy by time slice

A partial copy transfers only a section of production, usually a time frame: for example, the documents from the last 90 days. For the target system to work from a business perspective, all objects that these documents refer to have to come along too. These include master data, preceding documents and open items, even if they are years older. If one link in the document chain is missing, tests fail because of missing data rather than because of errors in the program.

Implemented correctly, a partial copy combines the realism of a full copy with a fraction of the memory. The limitation: edge cases that only exist in older data and do not occur in the time frame are missing. For tests around year-end closing, you should therefore choose the time frame to match the fiscal year.

The standard client copy has no concept of a time frame. A makeshift solution is to delete or archive data in the target system after a full copy. However, this only saves memory afterwards and makes the refresh longer. In ECC landscapes, partial copies were often made with SAP TDMS, which was developed for ECC. According to SAP Note 2696183, TDMS is not supported in the SAP S/4HANA context. What this means for the transition is described on the page SAP TDMS alternative for S/4HANA.

Generating SAP test data: manual, automated, synthetic

Instead of taking data from production, you can create it in the test system itself. Three variants are common:

Manual: Key users or testers create master data and documents through the application. This takes time, but delivers data that fits the test case exactly.
By test automation: Test scripts create their own data before running the actual test. In eCATT, for example, test data is kept separately from the scripts in test data containers and can be reused.
Synthetic: Generators produce data according to rules or a statistical model, including in large volumes, for example for load tests.

In SAP, one basic rule applies: create data through the application logic, i.e. via transactions, Fiori apps, BAPIs or released APIs, not directly in tables. A sales order writes to many tables, assigns numbers, sets statuses and builds the document flow. At the latest, the billing document posts to financial accounting. Anyone who writes around the application creates inconsistent data.

The limitation of all self-generated data: it only contains what someone anticipated. Master data that has grown over time, legacy data from the migration and rare process variants are missing. For development, training and automated regression tests, that is an advantage; for integration and acceptance tests, it is a risk. If synthetic data is derived from production data, for example via a trained model, clarify with your data protection team whether it allows inferences about real people.

Test data management in S/4HANA: which approach for what

Test data management means defining for each test system which data it needs, where that data comes from, how often it is refreshed and how it is protected. It complements test management, which organises test cases, test plans and test runs, in SAP landscapes for example with SAP Cloud ALM. The purpose of the system is decisive:

Development: Customizing and a small amount of targeted data are usually enough. Developers create this data manually or by script; production data is rarely needed here.
QA and integration testing: Production-like data with complete document chains across modules and interfaces. A partial copy by time slice or a client copy is suitable, masked in either case.
Regression testing: A reproducible starting point. Automated tests create their own data or select it at runtime. That way, they also survive the next refresh.
Support and error analysis: Data that is as current as possible, so that errors from production can be reproduced. What counts here is how quickly and how often the system can be refreshed.
Training: Stable, easy-to-understand sample data without real people. A practical option is a template client from which the training client is set up again before each course by local client copy.
Performance testing: Realistic data volumes. This usually requires a system copy. Synthetic data helps when future growth is to be simulated.

This also determines the size of the SAP HANA test system. Because HANA keeps the data in main memory, the data volume determines the RAM requirement. If you fill QA, test and sandbox according to their purpose rather than by full copy, you can also size them according to their purpose. More on HANA memory in non-production systems

Close to production and lean: time slice with masking

For QA, test and support systems, a partial copy is often the best compromise: real document chains, less memory, shorter refreshes. This is where the Data Refresh Operator (DRO) comes in. It copies a time slice, for example the last 90 days, and adds all dependent objects from earlier years. Dependencies are resolved up to the fixpoint – the verifiable point at which no new objects are added. Masking is integrated: rules are maintained centrally in the control system and applied during export or import. No BDLS run after the import: DRO replaces logical system names during the import, before they are written to the database.

–75%: HANA RAM in non-production
–60%: Storage & backup

Guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles.

DRO runs on SAP S/4HANA from release 2023 and replaces the client copy, not the system copy. For performance tests with the full data volume, the system copy remains the right approach. Which method fits when is shown in the comparison of client copy, system copy and time slice. We are happy to discuss with you which test data your systems really need: Book a demo.

Sources

SAP Note 2696183: TDMS components when installing and upgrading S/4HANA 1809/1909 (SAP Support Portal, login required)
BSI, IT-Grundschutz Compendium, 2023 edition: Module OPS.1.1.6 Software Tests and Approvals (in German)
SAP Help: Organizing Test Data in eCATT (SAP NetWeaver 7.3)
SAP Support: SAP Cloud ALM for Implementation: Test Management
dsgvo-gesetz.de: Art. 5 GDPR: Principles relating to processing of personal data (in German)

Test data for S/4HANA: full copy, partial copy or generation?