Lesson 6 of 6
Testing approval scenarios
8 min
Approval tests are some of the most valuable tests in procure-to-pay, and some of the most often done badly. The classic mistake is a tester with a super user who creates a PO, approves it from their own inbox and records "pass." That proves nothing about thresholds, routing or authority. Contoso's approval tests are built around boundaries, real roles and the approval history as evidence.
Boundary values
Thresholds are numbers, so test both sides. For Contoso's $25,000 PO threshold, create POs at $25,000.00 and at $25,000.01 (the rule says "above", so $25,000.00 must not start approval). For the $100,000 threshold, do the same. Also test the condition dimensions you use: a PO in plant 1720 if the conditions are plant-specific, a different document type, a different purchasing group.
| PO value | Expected workflow | Expected approvers | Evidence |
|---|---|---|---|
| $25,000.00 | Default: automatic approval | None | Status released at save; output sent |
| $25,000.01 | PO 25k to 100k | Purchasing manager | History: one step, approver name and time |
| $99,999.99 | PO 25k to 100k | Purchasing manager | History: one step |
| $100,000.00 | PO 100k and above | Purchasing manager, then plant controller | History: two steps in sequence |
The scenario set
| Test | What it proves |
|---|---|
| AP-01 to AP-04 thresholds | Correct definition, steps and approvers at each boundary |
| AP-05 rejection | Rejected PO is not output; buyer sees status and reason |
| AP-06 rework (if used) | PO returns to buyer; workflow continues as configured after resubmission |
| AP-07 value increase after approval | Workflow restarts; change output held until re-approval |
| AP-08 value decrease after approval | Per design: no restart |
| AP-09 substitution | Substitute receives and approves; history shows who acted |
| AP-10 self-approval | Buyer who also holds the approver role cannot approve own PO, or the design gap is recorded |
| AP-11 recipient not maintained | Team function empty for plant 1720: behavior is visible and handled, not a silent stall |
| AP-12 requisition approval | Self-service request at $999 and $1,000; blocked items cannot be converted |
| AP-13 classic release (if kept) | Document type still on release strategy releases in ME29N with the right code |
Contoso's approval test set.
Evidence
The best evidence is the approval history on the document: which workflow definition started, which steps ran, who received each step, who acted, what they did and when. For POs it is visible from the PO in Manage Purchase Orders; for classic release strategies, the release strategy tab shows codes and status. Add the output status (sent or not) to prove that blocking works, and screenshots or exports of the definition order as configured in the tested client.
- PrepareTest users: buyer, purchasing manager, plant controller, substitute; teams maintained for 1710 and 1720
- CreateBuyer creates PO at the boundary value
- RouteCheck the inbox of each expected approver, and that others do not receive it
- ActEach approver acts with their own user
- VerifyApproval history, PO status, output status
- RecordEvidence attached to the test case with tester, client 100, date
Negative routing checks matter as much as positive ones. When a $150,000 PO is approved by the purchasing manager, confirm that the plant controller received step 2, and that a buyer with no approval role never saw the item. Missing team data is a frequent go-live defect: if no one holds "plant controller" for plant 1720, what happens to the PO? The design should define it, and the test should prove it.
Approval tests also need maintenance after go-live. Every change to a threshold, a team assignment or a document type's approval method is a change to a key control, so the affected boundary tests should be rerun and their evidence kept with the change request. Keep the approval test set small and sharp enough that this is realistic: a dozen well-chosen cases that run in an afternoon are worth more than a hundred that nobody repeats.
What would you do?
AP-02 passes in client 100, but Priya notices that all tests were run by one tester logging in as each user in turn, using a shared password list. What should she do?
- Test both sides of every threshold and every condition dimension in use.
- Use real roles or controlled per-role test users; never self-approve as a super user.
- Evidence: approval history, PO status and output status, plus the configured definition order.
- Include rejection, restart, substitution, self-approval and missing-recipient cases.
Check your understanding · not graded
Lesson check
1. Which pair of values tests a $25,000 threshold?
2. What is the best evidence for an approval test?
3. Why is a super user approving their own PO a poor test?
4. What should a value-increase test after approval show?