Testing the hand‑offs: where SAP processes become enterprise processes

The question

Testing is organised the way delivery is organised: by system, by module, by team. Finance tests finance. The middleware team tests the interfaces. The warehouse team tests warehouse management. Each does a competent job of the thing they own.

A business process does not respect that structure. It moves through several of those areas in sequence, and the interesting failures happen in between.

What we see in programmes

The characteristic defect is not a component failing. It is two components that each behave correctly according to their own specification, and a business process that does not work as a result.

A field is truncated on the way out, within an agreed length, and means something different when it arrives. A status is set by one system and interpreted differently by the next. A document flows successfully and lands in a queue nobody monitors. A reversal is processed on one side and never propagated to the other.

Every one of these passes component testing. Every one is found by the business.

The structural reason is simple: a boundary has two owners, and each one’s test scope stops at the boundary. Neither is being negligent. The boundary is genuinely at the edge of both plans, and things at the edge of two plans are usually in neither.

A better way to think about it

Four kinds of boundary, worth naming separately because they fail differently.

Module boundaries inside SAP. Procurement to inventory to finance. These feel safe because it is all one system. They are not automatically safe, because configuration is owned by different people with different assumptions.

System boundaries. SAP to a warehouse system, a bank, a tax engine, a scanning solution, an e-invoicing platform. Usually tested as interfaces — message goes, message arrives — rather than as processes.

Organisational boundaries. The point where the process moves between teams. Buyer to approver, warehouse to accounts payable, shared service centre to local finance. These carry procedural assumptions that no interface specification records.

External boundaries. Suppliers, customers, logistics partners, authorities. The ones with the longest feedback loop, because you find out when they tell you.

A seam is the one place where nobody’s test plan ends. That is why defects collect there.

What good looks like

A named owner per end-to-end process, not per component. Somebody whose scope is the whole path. Without this, boundary testing has no natural home and will be nobody’s priority.

Boundary scenarios written explicitly. Not “test the interface” but “raise the requisition, approve it, receive the goods in the warehouse system, post the invoice, confirm the accounting entry” — as one scenario, crossing every boundary it crosses in production.

Reversal and correction paths included. Forward flows get tested. Cancellations, reversals and corrections cross the same boundaries in the opposite direction and are tested far less often, which is why they cause disproportionate trouble.

Real message volume for external partners. Sample messages exercise the cases you designed for. Production traffic exercises the cases you did not.

Someone watching the queues. A surprising share of boundary defects are documents that went somewhere and sat there. Nothing failed. Nothing was processed.

Questions leadership should ask

For each critical process, who owns it end to end? If the answer is a list of people, the boundaries need explicit scope.

Which scenarios cross a system boundary in a single test, rather than testing each side separately?

Have we tested reversals and corrections across boundaries, or only forward flows?

Who is monitoring the queues during test cycles?