Lesson 5 of 5
Testing approvals
8 min
Approval rules are controls. Auditors rely on them, and the business assumes they work. Yet they are among the least tested parts of many SAP projects, because the "happy path" (submit, approve, done) passes and nobody tries the edges. This lesson gives you a test pattern you can apply to every workflow scenario in scope: for each workflow, design tests along six dimensions. Most defects hide in the first three.
The test dimensions
- Boundaries. For every amount condition, test just below, exactly at and just above the threshold. "Greater than 25,000" and "greater than or equal to 25,000" differ at exactly $25,000.00.
- Routing. Prove each workflow catches the documents it should and no others: right company code, right purchasing group, right document type. Include a document that matches no workflow and record what happens.
- Recipients. Confirm the task reaches the expected person or team member, and does not reach the requester.
- Decisions. Approve, reject, and the resubmission after a rejection or a change.
- Substitution and forwarding. A substitute receives and can complete the task; a forwarded task arrives.
- Multi-step and step conditions. A document above the second threshold goes through both steps in the right order; one below it goes through only the first.
A worked example. Contoso's PO workflow for plant 1710: step 1 purchasing manager if the total net amount is greater than $25,000; step 2 plant controller if greater than $100,000. Priya's test set:
| Test | Data | Expected result |
|---|---|---|
| Below threshold | PO for $24,999.99 | No workflow from this rule; record whether the PO is released automatically |
| At threshold | PO for $25,000.00 | As specified by the policy: here "greater than", so no approval |
| Just above | PO for $25,000.01 | One task for the purchasing manager; PO unreleased until approved |
| Two steps | PO for $120,000 | Manager approves, then a task for the plant controller; released after both |
| Reject | PO for $48,000, manager rejects with comment | PO stays unreleased; buyer sees status and comment |
| Change after approval | Approved PO, quantity increased | Behavior per scenario settings: new approval or not; record and confirm with Dan |
| Substitution | Manager has a planned substitute | Substitute sees and completes the task; log shows the substitute |
| Other plant | PO for plant 1720, $48,000 | Not caught by this rule; caught by the Chicago rule |
Evidence and test users
Two pieces of evidence prove an approval test. The workflow log shows which workflow and steps ran, who received each task, who acted, what they decided and when. The document status shows the business result: the PO is released (or not), the journal entry is posted (or returned). Capture both. In Private Edition and on-premise, technical logs are also available in SAP GUI (for example, the work item and workflow log transactions), which helps when a task never arrives.
Approval tests also need several test users with realistic roles: requester, first approver, second approver, substitute. Testing with one powerful user who has every role proves nothing about routing and hides authorization defects. Agree the users with the security team early; this is one of the most common causes of blocked approval tests.
What would you do?
Priya's team reports that all 12 PO approval tests passed. You notice every test used amounts of $50,000 or more, and the tester was also the approver. What do you do?
- Test approvals across boundaries, routing, recipients, decisions, substitution and multi-step logic.
- Test just below, exactly at and just above each threshold.
- Use separate test users for requester, approvers and substitutes.
- Evidence is the workflow log plus the document status, including negative cases.
Check your understanding · not graded
Lesson check
1. A rule says "total net amount greater than 25,000 USD". Which test values best probe the boundary?
2. Which two pieces of evidence best prove an approval test?
3. Why should requester and approver be different test users?
4. Why include a document that matches no workflow?