Lesson 6 of 6
Evidence, exit criteria and sign-off
8 min
Listen to this lesson
At the end of a cycle, someone has to say "this process works." For integration and end-to-end testing that is usually the process owner, supported by the test lead. At Contoso, Dan signs procure-to-pay and record-to-report, Maria leads order-to-cash for the business, and Priya presents the evidence. Sign-off is only as strong as the evidence and the criteria agreed before the cycle started.
Integration sign-off is different from signing a single test case. The process owner is not saying "every step passed." They are saying "I have seen enough proof, across the boundaries that matter, to accept this process for the next stage, and I know which risks remain." That makes three things essential: criteria agreed in advance, evidence that can be checked, and a written list of what is not proven. Without the first, the gate moves every time the plan slips. Without the second, sign-off rests on trust. Without the third, the risks surface in hypercare.
Entry and exit criteria
| Criterion | Entry (before the cycle) | Exit (to close the cycle) |
|---|---|---|
| Scope | Scenario list approved by process owners | All in-scope scenarios executed; any descoped ones approved in writing |
| Environment | Transports imported to QAS client 100; interfaces connected; jobs scheduled | No environment issues open that affect results |
| Data | Master data and, for later cycles, migrated data loaded and reserved | Data issues found are logged as defects or migration findings |
| Defects | Known defects from the previous cycle triaged | No open critical or high defects without an approved workaround and fix date |
| Evidence | Templates and data sheet ready | Every passed scenario has checkpoint evidence at every boundary |
Example criteria. Agree the exact thresholds in the test strategy.
What an evidence pack contains
- The scenario ID, level and cycle, and the variants it carries.
- For each step: executed by, date and time, input document, output document, checkpoint result.
- For each interface boundary: message or IDoc number, final status, and the business document it created.
- The financial reconciliation: journal entries, GR/IR or receivable clearing, amounts versus expected.
- Deviations and workarounds used, with the defect numbers that explain them.
Evidence does not have to mean screenshots of every screen. Document numbers with statuses are stronger, because anyone can look them up again in the test system. Use screenshots for things that cannot be looked up later, such as a portal screen in a partner's test environment or an error message that disappears after reprocessing. Keep the evidence where the test case lives. If the program uses SAP Cloud ALM, attach it to the test run, so a reviewer can go from the test plan to the step result to the document numbers without hunting through shared folders. Ask a second person to spot-check a sample of passed scenarios before the sign-off meeting; finding a missing journal entry in your own review is much cheaper than having the process owner or an auditor find it.
- Were all in-scope scenarios executed?Yes → next question · No → approved descoping, or extend the cycle
- Does every passed scenario have evidence at every boundary?Yes → next question · No → complete the evidence before sign-off
- Are open defects within the agreed exit criteria?Yes → next question · No → fix and retest, or record a risk acceptance by the process owner
- Were any chains completed on prepared data?Yes → rerun the full chain or list the unproven boundary as an open risk · No → recommend sign-off
Defects and retests
Defects found in integration testing need the same discipline as any other: severity based on business impact, a clear owner, and a retest that reruns enough of the chain to prove the boundary. A fix to an inbound mapping is not retested by posting the invoice manually; it is retested by sending a new message through the boundary. Decide how far back the retest must start. A fix in billing output can be retested from an existing delivery; a fix in copy control between order and delivery needs a new order. When a fix touches shared configuration or a shared interface, rerun one other scenario that uses it, because integration fixes have a habit of breaking a neighbor. Track retests in the same cycle report as first runs so the process owner sees the full picture: how many scenarios passed first time, how many passed after a fix, and how many are still open.
- Was the fix in an interface mapping?Yes → send a new message through the boundary; never post the document manually · No → next
- Was the fix in billing output?Yes → retest from an existing delivery · No → next
- Was the fix in copy control between order and delivery?Yes → retest from a new order
- Does the fix touch shared configuration or a shared interface?Yes → also rerun one neighboring scenario that uses it · No → retest this chain only
What would you do?
End of SIT cycle 3. Two high-severity defects are open: one on partial-delivery billing in O2C-03, one on the bank file format in P2P-01. Grace wants Dan to sign procure-to-pay today to keep the plan green. What should Priya recommend?
- Agree entry and exit criteria before the cycle, and hold to them at the end.
- Evidence is document and message numbers with statuses at every boundary, plus reconciliation.
- Bypassed boundaries and accepted defects must be listed as risks with owners and dates.
- Retest integration fixes by sending a new message through the boundary, not by a manual post.
Check your understanding · not graded
Lesson check
1. Which is stronger evidence for an inbound invoice checkpoint?
2. A mapping fix for inbound invoices has been transported. How should it be retested?
3. Who usually signs off an end-to-end process such as procure-to-pay?