Lesson 2 of 6
Workflow and approver path coverage
10 min
Listen to this lesson
The rule-based workflow is a state machine written down in decision tables. That is good news for testers: the paths are finite and listable. For each change request type, the single-value decision table says, for a given current step, previous action and optional condition, what the next step and new status are. The user-agent decision table says who processes each step. The non-user-agent table defines background steps such as activation. Test design starts by reading these tables.
From decision table to test cases
| Current step | Previous action | Condition | Next step | Agent |
|---|---|---|---|---|
| 00 Request | Submit | none | 10 Steward check | Steward team (org unit) |
| 10 Steward check | Send back | none | 00 Request (revision) | Requester |
| 10 Steward check | Approve | Bank data present | 20 Finance approval | Dan (finance approver role) |
| 10 Steward check | Approve | No bank data | 90 Activation | Background |
| 20 Finance approval | Approve | none | 90 Activation | Background |
| 20 Finance approval | Reject | none | 10 Steward check | Steward team |
| 90 Activation | Activation failed | none | 10 Steward check | Steward team |
An illustrative extract of Contoso's routing for the "change supplier" request type. Real step numbers, actions and statuses come from your configuration.
Each row becomes at least one test case: put the request in the current step, take the action with data that makes the condition true, and check the next step, the new status and who received the task. This is transition coverage. Contoso's "change supplier" type has 14 rows, so 14 transitions to cover, plus the paths that combine them.
Paths, not just transitions
- Loop paths: send back and resubmit twice; reject at finance, fix, approve. Check that the history keeps every comment.
- Condition boundaries: a change that adds bank data, removes it, or only changes the bank account holder name. Which counts as "bank data present"?
- Four-eyes: the requester must not be able to approve their own request, even if they hold the approver role.
- No agent found: remove the role from all users in a test and check that the request is visibly stuck and monitored, not silently lost.
- Deadlines and escalation: if a step has a deadline, check what happens when it passes.
- Substitution: when Dan is on leave, does his substitute receive the finance approval, and is the substitute's approval recorded as such?
Agent determination
Agents can be users, organizational units, positions, jobs or roles, depending on configuration. Test with the same assignments production will use. If finance approval goes to the members of an organizational unit, the test must use a user who is a member through the org structure, not a user given the task directly. Then test the negatives: a user outside the unit must not see the task, and a user who loses the assignment must stop receiving new tasks.
| Test | Data or setup | Expected result |
|---|---|---|
| Positive agent | Bank change by Omar; Dan in the finance approver role | Task in Dan's inbox only |
| Wrong user | Maria logs on and searches for the task | Task not visible to Maria |
| Self-approval | Dan requests a change to a supplier he also approves | Approval by Dan refused; another approver required |
| No agent | Finance approver role removed from all test users | Request visible as stuck in monitoring; alert raised |
| Substitute | Dan absent, substitute set | Substitute gets the task; history shows the substitute |
Parallel steps and notifications
Some change request types send a request to several approvers at the same time, for example finance and purchasing for a new supplier, and continue only when all have decided. Test every combination of the parallel decisions: both approve, one rejects, both reject, and one decides long after the other. Check where the request goes after a mixed result and whether the slower approver's task disappears from the inbox when it is no longer needed. Also test the notifications users rely on: if Dan works from e-mail notifications, the test must prove that the e-mail arrives, links to the right task and does not expose bank data in the message text.
Evidence that holds up
For each workflow test, keep the change request number, the user who acted at each step, the step history from the change request, and the active record after completion. The step history is the strongest evidence, because it shows the path the system actually took, not the one the tester intended. Auditors reviewing dual control on supplier bank data will ask for exactly this.
What goes wrong in testing
| Pitfall | Consequence | Prevention |
|---|---|---|
| Test user holds requester and approver roles | Four-eyes defects invisible | Separate users; one explicit self-approval test |
| Decision table edited during the test cycle | Results not reproducible | Record the table version with each test run |
| Only the first transition of each step tested | Rejection and failure branches untested | Measure transition coverage per request type |
| Tasks approved by e-mail link only | Inbox behavior and substitution untested | Test each channel users will really use |
Typical workflow test failures.
What would you do?
During acceptance, Dan approves a supplier bank change that he requested himself for an urgent payment. The request activates. Hannah says this is "fine because Dan is the finance owner." What should Priya do?
- Each decision table row is a transition; cover all of them per change request type.
- Test loops, condition boundaries, four-eyes, no-agent, deadlines and substitution.
- Use production-like agent assignments and one user per role.
- Keep the step history as evidence; it shows the path the system really took.
Check your understanding · not graded
Lesson check
1. What does transition coverage mean for a rule-based workflow?
2. Which test proves the four-eyes principle for supplier bank data?
3. Why test with agents assigned through the org structure?
4. What is the strongest evidence of the path a request took?
5. Finance approval goes to nobody after a role change. What should a good test design include?