Lesson 3 of 6
Environments and data
12 min
Listen to this lesson
Most SAP test cycles that fail do not fail because of bad tests. They fail because the environment was not ready or the data was wrong. The strategy should settle, once, which landscape tier hosts which level, how often it is refreshed, and where each level's data comes from.
Landscape tiers and test levels
| Tier | Contoso system and client | Test levels hosted | Notes |
|---|---|---|---|
| Sandbox | SBX | Fit-to-Standard demos, prototyping | No formal testing; can be reset |
| Development | DEV | Unit tests | Configuration and code built here |
| Quality assurance | QAS client 100 | String, role, SIT, data migration, UAT, regression | Transports imported in controlled waves |
| Training | QAS client 200 | Training only, not testing | Kept separate so training does not corrupt test data |
| Pre-production (if contracted) | PRE | Performance, cutover rehearsal checks, OAT | Production-like size and configuration |
| Production | PRD | Post-go-live verification only | No test transactions beyond agreed checks |
Contoso's landscape and the levels each tier hosts. Your landscape depends on the contract and deployment option.
For Public Edition, the landscape is defined by SAP (typically development, test and production tenants), so the strategy adapts the levels to it rather than designing tiers. For Private Edition, the number of systems depends on the RISE contract; check whether a pre-production system is included before planning performance and rehearsal testing there.
Transport and refresh rules
State how changes reach the test system and when. In SAP Cloud ALM, features carry transports through the landscape, so the strategy can say: during a cycle, only features for fixes of S1 or S2 defects are imported, in agreed windows, and every import is announced to testers. State the refresh approach too. A system copy from production refreshes realistic data but wipes test data and in-flight test documents; plan refreshes between cycles, never during one.
- Cycle entryTransport baseline frozen; data loaded; users and roles ready
- During the cycleOnly approved fix features imported, in announced windows
- Cycle exitResults recorded; open defects carried to the next plan
- Between cyclesNext transport wave imported; refresh or reload if planned
- Next cycle entryNew baseline confirmed against entry criteria
Data approach per level
| Level | Data source | Why |
|---|---|---|
| Unit and string | Small, hand-built master data | Fast and focused; owned by the builder |
| SIT | Migrated data from a load cycle, plus targeted test records | Proves processes work with the data they will really use |
| Data migration | Full or representative loads with reconciliation | Proves completeness and correctness |
| UAT | Migrated data that business users recognize | Key users judge results against real customers, products and prices |
| Performance | Production-like volumes | Response and runtime depend on volume |
| Regression in Run | Stable, reusable data sets refreshed on a schedule | Repeatable results release after release |
Data approach by level.
If any level uses data copied from production, the strategy must state how personal and sensitive data is protected: which fields are masked or scrambled, who may see unmasked data, and how that is verified. Contoso's customer master includes contact names and bank details for some fleet customers, so Priya's strategy requires masking of personal and bank fields in every non-production copy, with a sample check by the data protection officer before UAT.
- Copy from productionSystem copy into a non-production client, between cycles only
- MaskPersonal and bank fields scrambled in customer and supplier master
- RestrictOnly named people may see unmasked data
- Sample checkData protection officer verifies a sample before UAT
- ReleaseTesters and key users get access to the masked copy
Tools, described without brand names
Describe tools by capability, not by vendor, and justify each one. For Contoso: test management, requirements traceability and defects in SAP Cloud ALM; regression automation through a provider integrated with Cloud ALM's test automation interface, to be selected by a proof of concept on Contoso's own processes; a load-generation capability for performance testing; and the SAP tools for data migration and reconciliation. A capability description survives a tool change; a screenshot of a tool does not.
What would you do?
Midway through Contoso's SIT cycle 2, Basis proposes a system copy from production into QAS "to get fresher data". What should the strategy's rules lead Priya to say?
- Assign each test level to a landscape tier and keep training separate from testing.
- Control transports during cycles and refresh only between cycles.
- Define the data source per level, with masking rules for any production-derived data.
- Describe tools by capability, not vendor, and link to owners' landscape and calendar documents.
Check your understanding · not graded
Lesson check
1. When should a QAS refresh from production be scheduled?
2. Which data suits UAT best?
3. How should the strategy describe test tools?
4. What must the strategy state if any test data comes from production?