Lesson 1 of 6
Reference architecture
10 min
Listen to this lesson
Continuous testing means that every change, from an ABAP transport to a BTP deployment to an SAP release, is checked automatically and quickly enough that the result can still change the decision. In a single application that is mostly a pipeline problem. In an SAP enterprise it is an architecture problem: the order-to-cash process at Contoso Motor Co. runs through SAP S/4HANA, a BTP extension, an EDI connection to fleet customers, a carrier's tracking service and the bank. Testing it continuously needs environments, data, substitutes for unavailable systems, monitoring and governance that all fit together.
This expert course designs that architecture for Contoso after its conversion to SAP S/4HANA Private Edition: systems CMD, CMQ and CMP, BTP subaccounts for development, test and production, SAP Cloud ALM for test management and operations, and the Wave 2 acquisition of Alternadores del Norte in company code 1910. It assumes you know gates and pipelines (sap-tau-304) and data strategy for automation (sap-tau-302).
Layers from code to process
The layers are not a pyramid you build once; they are a budget. Each lower layer is faster, cheaper and more stable than the one above, so you push every check as low as it can go and keep the upper layers for what only they can prove: that the integrated business process works. The ISTQB Test Automation Engineering syllabus maps the same idea onto environments: low-level tests and static analysis in the build environment, black-box UI and API suites in an integration environment, non-functional and acceptance work in preproduction, and monitored practices in production.
Cross-cutting capabilities
Around the layers sit the capabilities that make them work at enterprise scale. Each one gets its own lesson in this course.
| Capability | Question it answers | Lesson |
|---|---|---|
| Environment orchestration | Is the right system, at the right version, with the right connections, ready now? | 2 |
| Virtualization and mocks | What do we test against when a dependency is unavailable, costly or unpredictable? | 3 |
| Data provisioning | Where does valid, private-safe data come from for thousands of runs? | 4 |
| Observability | What happened inside the systems while the test ran? | 5 |
| Governance | Who owns which tests, standards and tools, and how is value measured? | 6 |
| Test management | What was tested, against which requirement, with what result? (SAP Cloud ALM) | All |
Cross-cutting capabilities and where this course covers them.
Inside the automation solution
The ISTQB syllabus describes a generic test automation architecture with layers for test generation, test definition, test execution and test adaptation. The adaptation layer is what connects tests to each kind of system under test. In SAP terms that means adapters for SAP GUI, for Fiori and UI5, for OData and SOAP services, for IDocs and for non-SAP interfaces. Keep business-level test definitions independent of these adapters: the step "create sales order for a fleet customer" should not care whether it is executed through the Fiori app, the API or, in a different test, both.
| Design choice | Fragile | Robust |
|---|---|---|
| Test definition | Scripts written against screens | Business steps mapped to adapters |
| Interfaces | Real partner systems only | Real, virtual or mocked, chosen per test level |
| Data | Shared, remembered records | Provisioned per run or reserved from pools |
| Results | Tool-local dashboards | Results in Cloud ALM, linked to requirements and features |
| Diagnosis | Screenshots only | Test logs correlated with system monitoring |
What would you do?
Grace asks Priya to make the full end-to-end order-to-cash suite run on every ABAP transport release so "nothing slips through". It takes three hours and needs the carrier and EDI partners. What should Priya propose?
- Continuous testing in SAP is an architecture problem spanning systems, partners and delivery flows.
- Layer tests from code to process; push each check as low as it can go.
- Cross-cutting capabilities: environments, virtualization, data, observability, governance and test management.
- Keep business test definitions independent of the adapters for GUI, Fiori, services and IDocs.
- Map layers against delivery flows to find gaps before buying or building anything.
Check your understanding · not graded
Lesson check
1. Why push checks to the lowest layer where they can run?
2. In the ISTQB generic architecture, which layer connects tests to the specific systems under test?
3. Which test layer is best suited to proving that order to cash works across S/4HANA, BTP and partners?
4. After go-live, which Contoso environment plays the preproduction role in the ISTQB environment mapping?