Lesson 1 of 5
Levels
8 min
Listen to this lesson
Most SAP programs test interfaces in one big phase called SIT, late, with every system and partner connected at once. When something fails, nobody knows whether it is the mapping, the partner, the network, the master data or the process. A layered strategy tests each concern at the cheapest level that can prove it, so that by connected SIT the remaining defects are the ones only connected testing can find. At Contoso the same strategy serves twice: for the S/4HANA go-live, when interfaces still run on SAP Process Orchestration (test system XQ1, port XQ1_PO), and again for each wave that moves interfaces to the SAP Integration Suite test tenant. Examples that use the test tenant come from those waves, such as the Lakeside order flow in Wave 1.
Test levels, from the standard
The ISTQB Certified Tester Foundation Level syllabus (v4.0) describes test levels that map well onto integration work. Component testing tests a part in isolation. Component integration testing tests the interfaces and interactions between components. System testing tests a whole system's behavior. System integration testing tests the interfaces between the system under test and other systems and external services. Acceptance testing validates readiness for use. For an SAP landscape, the components are mappings, scripts, flows, APIs and the business systems at each end.
What each level proves
| Level | Proves | Cannot prove | Owner at Contoso |
|---|---|---|---|
| Mapping and component | Each transformation is right for every variant | That systems can talk to each other | Integration developers; Kenji's team for ABAP |
| Contract | Both sides agree on structure and rules | That the content makes business sense | Integration developers with partner contacts |
| Interface in SAP landscape | Flows, adapters, error handling work up to a stub | Partner acceptance and real routes | Theo's integration team |
| Connected SIT | Real routes, security and partner processing | The full business process and roles | Priya's test team with partners |
| End-to-end | Business outcome across systems and roles | Resilience under failure and load | Key users such as Maria, with Priya |
| Error, volume, recovery, operational | Survives failures and peaks; can be operated | Business correctness of every variant | Integration team, Basis (Sam), operations |
What each integration test level proves and who owns it on Contoso's program.
The right column matters as much as the others. Each level needs an owner, an environment, entry criteria and evidence. A level that "everyone" owns is a level nobody runs.
Risk decides depth
Not every interface needs every level at full depth. Contoso classifies its 60-plus interfaces by business impact and technical complexity. A supplier order interface feeding production gets every level. A weekly product text feed to the web shop gets mapping tests, one connected run and monitoring proof. Write the classification into the test strategy, agreed with Grace and the process owners, so the depth is a decision, not an accident of time running out.
What would you do?
Contoso's test plan has a single "SIT" phase of four weeks for all interfaces, starting when every partner is connected. Priya has budget to restructure it. What change gives the biggest reduction in risk?
- Test each concern at the cheapest level that can prove it.
- ISTQB levels map to mappings, contracts, interface tests, connected SIT, end-to-end and acceptance.
- Every level needs an owner, environment, entry criteria and evidence.
- Set depth per interface by business impact and technical complexity.
Check your understanding · not graded
Lesson check
1. Which ISTQB test level focuses on interfaces between the system under test and other systems?
2. What can a mapping test NOT prove?
3. Why define an owner for each integration test level?
4. What should decide how deeply an interface is tested?