Environments and data

Tests need somewhere to run and something to run on. In SAP, both are architecture decisions: how many systems and clients, how they are refreshed, what data they hold, how that data is protected, and how partner systems are represented when they are not available. Poor decisions here cause more test delays than any defect.

The landscape as a test asset

Contoso's S/4HANA landscape has three systems, CMD, CMQ and CMP, with client 100 in CMQ for testing and client 200 for training. Architects decide whether that is enough. Typical additions are a pre-production system (a recent copy of production for upgrade rehearsals and performance tests) and separate clients for different test purposes. Each addition costs money and maintenance; each missing one creates contention, such as a dress rehearsal and an integration test fighting over CMQ.

Getting data in: copies, subsets and synthetic data

There are three main sources of test data. A copy of production gives realism but brings volume and personal data. SAP's client copy profiles show the granularity available within a system: for example, SAP_CUST copies client-specific customizing, SAP_UCUS adds user master records to it, SAP_APPL adds application data (master and transaction data) but no user master records, SAP_ALL copies all client data, and SAP_USER copies users and roles; all profiles except SAP_USER delete the target client's data first. A subset copies only selected company codes or periods. Synthetic data is created on purpose, ideally through released APIs or migration tools, so it is known, repeatable and free of personal data.

Privacy and data reset

Copies of production into test systems contain personal data about customers, suppliers and employees. The architecture must define how it is masked or scrambled, who checks that masking is complete, and which data never leaves production. Automated tests also need data that is fresh every run: either each test creates what it needs through APIs, or a reset job restores a known baseline before each run. Write data creation as reusable, versioned code next to the tests, not as a manual spreadsheet ritual.

When partners are not available

The bank, the carrier and the fleet-service portal are rarely available in CMQ when testers need them. Simulate them: a stub endpoint that accepts payment files and returns a status, a mock carrier service, a recorded set of portal messages. SAP's UI5 documentation describes the same idea for user interfaces: a mock server mimics back-end services so the UI can be developed and tested even when the service is incomplete or unstable. Simulations need owners and must be kept in line with the real contract.