Lesson 1 of 5
Why integration tests
12 min
By the time Contoso Motor Co. reaches integration testing, every team has tested its own process. Sales can create orders and invoices. Procurement can buy rotors and pay Lakeside Components. Production can build alternators. Finance can close a period. And yet, when the processes are connected for the first time, things break. This course is about finding those breaks before go-live, with one connected story that runs across order to cash, procure to pay, plan to produce and record to report.
Where integration testing sits
SAP's implementation guidance places integration testing in the Realize phase, after the solution is configured and before user acceptance testing, and expects it to be documented, for example in SAP Cloud ALM test management. In practice, projects often run two or three integration cycles, with data and scope growing each time.
Defects that only appear when processes connect
An integration defect is usually not a wrong setting inside one team's area. It is a setting in one area that another area depends on, and that nobody tested in combination. These are the defects that unit and string tests cannot find, because each team's test uses data it set up itself.
| What breaks | Caused in | Seen in | Why string tests missed it |
|---|---|---|---|
| Revenue posts to the wrong G/L account | Product sales data (account assignment group) maintained by the master data team | Billing and finance | Sales tested with a product the finance team had set up correctly |
| MRP creates no requisitions for rotors | MRP settings on CMC-RTR-200 maintained by production planning | Procurement waits for demand that never comes | Procurement created requisitions by hand in its own tests |
| Goods receipt posts to the wrong inventory account | Valuation class on the product, set by finance | Procurement goods receipt and inventory balances | Procurement only checked quantities |
| Production order variances settle to the wrong place | Settlement profile and cost object settings in controlling | Period-end close | Production confirmed orders but never ran settlement |
| Fleet orders block deliveries unexpectedly | Credit settings maintained by finance | Shipping | Sales tested with customers without credit limits |
Interfaces and batch jobs
Integration testing is also where interfaces and scheduled jobs meet real data for the first time. Contoso sends delivery notifications to a logistics partner, receives bank statements, and runs MRP, billing and the payment program as jobs. Each of these connects processes that people normally see as separate. An interface that passes a technical test with a sample message can still fail when a real delivery from the storyline carries a partial quantity or a Chicago shipping point. Put interfaces and jobs into the storyline at the point the business would use them, rather than testing them only in isolation.
The same applies to output. A billing document that prints correctly in a string test may print a different address or bank account when the customer was created by the master data team with a different address type. Include output checks in the storyline wherever a document leaves the company.
What integration testing proves
- Outputs of one process are valid inputs for the next: a planned order becomes a production order, a goods receipt allows a supplier invoice.
- Master data built by different teams works together on one transaction.
- Financial results add up across processes: inventory, cost of goods sold, revenue, receivables, payables and variances.
- Interfaces and batch jobs run in the right order with the right data.
- Roles can hand work to each other: one team's worklist fills with the other team's output.
What would you do?
Grace asks why Contoso needs a separate integration cycle when "every team has already passed its string tests". What is the best answer?
- Integration testing comes after unit and string tests and before UAT, and is formal and documented.
- Integration defects are caused in one area and seen in another.
- It proves outputs feed inputs, master data works together, and the money adds up.
- Focus on cross-team flows that post value.
Check your understanding · not graded
Lesson check
1. Which defect is most likely found only in integration testing?
2. How does SAP Activate treat string tests compared with integration tests?
3. Why did procurement's string tests miss the missing MRP settings on rotors?
4. Which area most needs a mandatory integration storyline?