Lesson 2 of 6
Scope and test levels for SAP
13 min
Listen to this lesson
The heart of a test strategy is two decisions: what is in scope for testing, and which test levels will prove it. In SAP programs both depend on the deployment option and on the SAP Activate phase.
Scope: start from the process scope
Your test scope is your solution scope, seen as risk. List the processes in scope from Fit-to-Standard (in SAP Cloud ALM, the solution processes in the project scope), the approved requirements, the interfaces, the reports and outputs, the data objects to migrate, and the roles. Then say explicitly what is out of scope, such as processes staying in ECC until a later wave, or a third-party system tested by its owner. An out-of-scope list prevents more arguments than any other paragraph.
- ProcessesSolution processes in scope from Fit-to-Standard
- RequirementsApproved requirements and gaps
- Interfaces and outputsInterfaces, reports and output forms
- Data and rolesData objects to migrate and business roles
- Out of scopeLater waves and systems tested by their owners, stated explicitly
For Contoso, scope includes order to cash for sales area 1710 / 10 / 00, procure to pay for purchasing org 1710, production for plants 1710 and 1720, finance close for company code 1710, 14 interfaces, 38 output forms and the migration of customers, suppliers, products, open orders and balances.
Test levels for an SAP program
| Level | Proves | Typical owner | When |
|---|---|---|---|
| Unit and string test | Configuration and code work in small pieces and short chains | Build team | Realize sprints |
| Business role (security) test | Each role can do what it should and cannot do what it should not | Security lead with functional leads | Realize |
| Data migration test | Loaded data is complete, correct and usable in processes | Data lead with business data owners | Realize load cycles; Deploy rehearsals |
| System integration test (SIT) | End-to-end processes across modules, interfaces and migrated data | Test lead | Realize, in cycles |
| Performance test | Critical processes and jobs meet response and throughput needs at volume | Technical lead | Late Realize |
| User acceptance test (UAT) | The business accepts the solution for its processes | Process owners, run by key users | Late Realize |
| Operational acceptance test (OAT) | The solution can be operated: jobs, monitoring, backup and restore, support handover | Operations lead | Late Realize or Deploy |
| Cutover rehearsal checks | The move to production works, on time, with reconciled data | Cutover manager with test lead | Deploy |
| Regression test | Changes and upgrades do not break working processes | Test lead, later the support organization | Each change; Run |
Test levels for an SAP S/4HANA program. Names vary; the strategy should define each one used.
Deployment option changes the levels
| Topic | Public Edition | Private Edition (RISE) | On-premise |
|---|---|---|---|
| Upgrade rhythm | Set by SAP; the test system is upgraded first, then development and production a few weeks later | Planned with SAP; SAP executes the technical upgrade | Planned and executed by the customer |
| Regression window | Fixed and short; must fit SAP's schedule | Agreed per upgrade or feature pack | Chosen by the customer |
| Standard test content | SAP Best Practices scripts; SAP's test automation tool for Public Edition | SAP Best Practices scripts; automation via a connected provider | Same as Private Edition |
| Extensions to retest | Key-user and developer extensions on released APIs | Classic and cloud-ready extensions, graded by clean core level | Any custom code; widest regression scope |
| Technical testing | Largely SAP's responsibility | Split: SAP runs infrastructure; customer tests business and integration | Customer's responsibility end to end |
For Public Edition, the strategy must plan regression around SAP's upgrade schedule, which is not negotiable, and should exploit SAP's standard automated tests. For Private Edition, like Contoso's RISE contract, SAP executes technical upgrades but the customer tests business processes, so the strategy must define a repeatable regression level from day one. For on-premise, the customer owns technical as well as functional testing, so OAT and performance testing carry more weight.
Activate phases and transition path
Map each level to Activate phases and to the transition path. A system conversion carries existing custom code and data into S/4HANA, so it needs strong regression and reconciliation testing of what already exists. A new implementation needs more process and integration testing and a larger data migration test. A selective data transition sits between the two. Contoso's path is a move from ECC 6.0 EHP 8 to Private Edition; Priya's strategy treats migrated financial balances and open orders as the highest-risk data, and gives data migration testing its own level with reconciliation sign-off by Dan.
| System conversion | Selective data transition | New implementation | |
|---|---|---|---|
| Carries over | Existing custom code and data | Chosen data and some processes | Little or nothing |
| Heaviest testing | Regression and reconciliation of what exists | Data selection, reconciliation and changed processes | Process, integration and data migration |
| Contoso focus | ECC 6.0 EHP 8 to Private Edition: migrated balances and open orders as highest-risk data | Not Contoso's path | Not Contoso's path |
What would you do?
Contoso's steering committee asks Priya to drop performance testing because "S/4HANA on HANA is fast". The MRP run for plants 1710 and 1720 and month-end billing for fleet customers are critical. What should the strategy say?
- Derive test scope from the solution scope: processes, requirements, interfaces, outputs, data and roles, with an explicit out-of-scope list.
- Define each level used: unit and string, role, data migration, SIT, performance, UAT, OAT, cutover checks, regression.
- Public Edition, Private Edition and on-premise differ in upgrade rhythm, regression window and technical testing ownership.
- Transition path changes emphasis: conversions need regression and reconciliation; new implementations need more process and migration testing.
Check your understanding · not graded
Lesson check
1. What should a test strategy's scope be derived from?
2. Which level proves the solution can be operated, including jobs, monitoring and support handover?
3. Under RISE with SAP Private Edition, who executes the technical upgrade?
4. Which transition path most needs regression and reconciliation testing of existing code and data?
5. Why include an explicit out-of-scope list?