Integration levels in SAP programs

Every SAP program has a moment when the unit tests are green and the business process still does not work. Contoso Motor Co.'s sales team proved that a sales order for 50 alternators CMC-ALT-100 saves correctly. The warehouse proved that a delivery can be picked and goods-issued in plant 1710 Detroit. Billing proved that an invoice posts. Then the first chained run produced an invoice with no journal entry, because the billing document was blocked for transfer to accounting. Each step passed on its own; the hand-off between them was never tested.

Integration testing exists to test those hand-offs. The trouble is that programs use the word loosely. One team says "integration test" and means two transactions in the same module run back to back. Another means the interface to the bank. A third means the full order-to-cash process with real users. If the test plan does not say which level a test belongs to, nobody can tell what has actually been proven, and the steering committee reads "integration testing 90% complete" without knowing whether a single message has crossed a system boundary.

Start with the vocabulary. The ISTQB Foundation syllabus (v4.0) separates component integration testing, which looks at the interfaces and interactions between components, from system integration testing, which looks at the interfaces between a system and other systems or external services. SAP programs add their own vocabulary on top. The layers below are the ones most SAP test leads use; the names vary between programs, so agree on them in the test strategy and stick to them.

Unit testOne transaction or app does what its configuration says: a sales order prices correctly in sales area 1710 / 10 / 00.

String testSeveral steps inside one module run in sequence: order, delivery, picking, goods issue in sales and logistics execution.

Cross-module integration testThe chain crosses module boundaries: goods issue posts to inventory and finance, billing creates a journal entry in company code 1710.

System integration test (SIT)The chain crosses system boundaries: purchase orders go out to the supplier portal, invoices come back through SAP Integration Suite.

End-to-end testA complete business process with its real roles, outputs, interfaces, batch jobs and reports, run on migrated or production-like data.

Each layer proves something the one below cannot.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-203

A string test is the informal bridge between unit and integration testing. It chains unit tests inside one area, usually run by the consultant who built the configuration. A cross-module integration test deliberately crosses an organizational or module boundary, for example logistics to finance. A system integration test adds the non-SAP or other-SAP systems: the supplier portal, the bank, a warehouse system, a tax engine, a planning system. An end-to-end test is the widest view: the business process as the business will run it, including the people who hand work to each other, the outputs they print or send, and the jobs that run overnight.

How SAP Activate frames it

In SAP Activate, implementation testing happens in the Realize phase. SAP's own test strategy guidance treats unit and string tests as informal: they happen as configuration is completed. Integration, end-to-end and data migration tests are formal, and SAP expects them to be documented, for example in the SAP Cloud ALM test management apps. User acceptance testing is run by business experts at the end of Realize, and regression testing belongs to the Run phase, when upgrades and changes arrive. SAP also recommends testing business processes in the test system only after integrations are set up and data is migrated, because that is the only way the results reflect real conditions. The test types are the same in SAP S/4HANA Cloud Public Edition; the main difference there is that SAP delivers standard test scripts and an SAP test automation tool for the public cloud, and the customer takes over regression testing of each upgrade after go-live.

Level	Typical owner	Contoso example	Formality
Unit	Functional consultant	Purchase order for rotor CMC-RTR-200 picks up the right price from Lakeside Components	Informal, notes in the build backlog
String	Consultant with key user	Purchase order, goods receipt into storage location 171A, quality inspection	Informal, but keep the document numbers
Cross-module integration	Test lead with module teams	Goods receipt posts to inventory and the GR/IR account in company code 1710	Formal test case and result
System integration	Test lead with integration team	Purchase order reaches the supplier portal; supplier invoice comes back and posts	Formal, with interface evidence
End-to-end	Test lead with process owners	Procure-to-pay from requisition to payment, including the payment run and bank file	Formal, signed off by the process owner

Who usually owns each level and how formal it is.

How SIT cycles are usually organized

SAP Activate does not prescribe a number of cycles, so programs choose their own. A common pattern is two or three integration cycles, each widening the scope and the realism of the data. Contoso's test lead Priya planned three, all in client 100 of the QAS system. Each cycle has entry criteria (what must be true before it starts, such as transports imported and interfaces connected) and exit criteria (what must be true to call it done); lesson 6 covers those in detail. The point here is that a cycle is a time box with a defined scope and level, not "testing until it feels right." Between cycles, the team fixes defects, imports the next set of transports and refreshes or reloads data, so each cycle starts from a known state.

Realize sprintsUnit and string testsInformal, done as each configuration item is finished.
SIT cycle 1Core SAP chainsCross-module flows with manually created test data; external systems stubbed or simulated.
SIT cycle 2Interfaces liveReal connections to the supplier portal, bank and carrier test endpoints; outputs and batch jobs included.
SIT cycle 3End-to-end on migrated dataFull processes on data from a mock migration, run by key users with the consultants watching.
End of RealizeUAT and sign-offBusiness acceptance, then exit into the Deploy phase.

A typical three-cycle plan. The number of cycles is a program decision, not an SAP rule.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-203

Key points

Unit, string, cross-module, system integration and end-to-end tests each prove a different thing.
Integration tests target the hand-offs between steps, modules and systems.
In SAP Activate, unit and string tests are informal; integration, end-to-end and data migration tests are formal and documented.
Most programs run two or three SIT cycles that widen scope and data realism; agree the plan in the test strategy.

How SAP Activate frames it

How SIT cycles are usually organized

Lesson check