SAP Integration Test Plan: Scope, Scenarios, Interfaces

Decision context

Integration testing in SAP fails in the seams. Every component works, every unit test passes, and the process still breaks where a document crosses a system boundary, where a queue restarts, or where a partner sends a field in a format nobody agreed to.

So the plan should be organised by end-to-end business scenario, not by module. Order to cash across SD, MM, FI and the third-party logistics interface is one scenario. Testing SD, then MM, then FI is not integration testing, it is three component tests.

The second organising principle is the interface inventory. Every interface in scope needs a direction, a protocol, a partner, a business owner, an error handling path, and a decision about whether it is genuinely connected in the test or substituted.

Scope the plan by end-to-end scenario

Write the scenarios first, then derive everything else from them. A scenario is a business outcome that crosses at least one system or module boundary.

Each scenario should carry the systems involved, the interfaces crossed, the master data required, the expected documents at each step, and the reconciliation point that proves it worked.

• The business outcome in one sentence, from the initiating event to the final posting or confirmation.
• Every system the scenario touches, including the non-SAP ones, and who owns each.
• Every interface crossed, with the direction and whether it is real or substituted in this cycle.
• The master data the scenario needs in every system, which is where cross-system test data breaks down.
• The expected documents and their key values at each hop, so a failure is localised rather than reported as the scenario failing.
• The reconciliation check that closes the scenario, usually a comparison between the initiating and the resulting values.

The interface inventory

The inventory is the part of the plan most likely to be incomplete, and an interface that is not in the inventory will not be tested and will not be in the cutover plan either.

• Interface identifier, direction, protocol, and the middleware or integration service in the path.
• The partner or system at the other end, and the named business owner on the SAP side.
• Frequency and volume, because a real-time interface and a nightly batch fail differently and need different tests.
• Error handling: where a failed message lands, who monitors that place, and how it is reprocessed.
• Restart behavior after an outage, including whether duplicates are possible and what prevents them.
• Whether the partner participates in this cycle. If not, what substitutes for them and what remains untested as a result.
• The cutover implication: freeze point, queue drain, and restart sequence for this interface.

Test data across systems

Cross-system test data is the single largest practical obstacle in SAP integration testing, and it is a planning problem rather than a testing problem.

• The same business entity must exist and be identifiable in every system the scenario touches, which usually means an agreed cross-reference for customer, material, vendor, and organisational unit.
• Data has to be refreshable between cycles, because a scenario that consumes an open document cannot be re-executed against the same document.
• Volume matters where the scenario involves a batch, a report, or a selection. A scenario proved on three records says nothing about a nightly run.
• Data ownership has to be named per system, including the non-SAP ones, or the test cycle stalls on a request nobody has accepted.
• Where partner data is involved, agree in advance what the partner will send and when they can send it.

Cycle structure and exit criteria

Two or three cycles is normal. Give each a purpose, and agree exit criteria before the first execution.

• Cycle 1: scenarios execute end to end with substitutions permitted. The exit is that the path exists.
• Cycle 2: real interfaces, real volumes where relevant, error and restart paths exercised deliberately.
• Cycle 3 if needed: regression after fixes, plus the negative and exception paths that cycle 2 uncovered.
• Exit criteria: every in-scope scenario passed on the final build, no open critical or high defects on scenarios required at go-live, every interface either tested live or with its substitution recorded as a named risk, and reconciliation evidence retained for each scenario.

What the workflow must cover

• Scenario-level impact. Relate the change to the end-to-end scenarios it affects, including the interfaces and process steps several edges away from the changed object.
• Interface coverage. Track which interfaces were exercised live and which were substituted, so the substitution is a recorded risk rather than an assumption.
• Cross-system traceability. Follow a document through its hops so a scenario failure names the step rather than the scenario.
• Reconciliation evidence. Retain the comparison that closes each scenario as an artifact rather than a verbal confirmation.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Write the end-to-end scenarios and derive the systems, interfaces, and data from them.
2. Build the interface inventory and confirm partner participation per interface.
3. Prepare cross-system test data with named owners and a refresh method.
4. Execute the cycles, exercising error and restart paths deliberately.
5. Exit against written criteria, retaining reconciliation evidence per scenario.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Scenario definitions
• Interface inventory with owners
• Partner participation confirmations
• Cross-system data cross-reference
• Per-hop document evidence
• Error and restart test results
• Reconciliation output
• Defect list with severity and owner

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A substituted interface is untested, and the plan should say so rather than count it as covered.
• Integration testing at reduced volume does not prove batch and interface behavior at production volume.
• Partner availability is a scheduling constraint no tool resolves, and it is the most common cause of a delayed cycle.

Buyer checklist

• Are scenarios defined end to end or by module?
• Which interfaces are substituted rather than connected?
• Who owns test data in each non-SAP system?
• Were error and restart paths exercised, or only the happy path?
• Is reconciliation evidence retained per scenario?