Check an approval workflow with clear acceptance criteria

Describe the outcome and starting state

For each important workflow, define who may act under which conditions and what state must be demonstrable afterwards. GOV.UK describes acceptance criteria as outcomes used to check that a user need is met. A broad promise such as “approval works” becomes testable through these conditions.

Example: approve an internal change request

This plan is entirely fictional. Request CH-27 starts as draft, moves to pending with a complete justification and may be set to approved by the assigned reviewer. Use synthetic data and suitable test accounts in a controlled test environment. The table contains expected results, not executed tests.

The final row assumes a definite rejection before the change. If only a response is missing, the stored state is initially uncertain; plan a separate test of the state actually stored.

Check state, permissions and feedback

A hidden button does not demonstrate access control. OWASP calls for appropriate permission checks on every request. Include direct calls and the actual stored state in the test. An on-screen success message is insufficient.

Set up each case with a defined starting state. Playwright recommends independent tests with controlled data and sessions. A previous case’s role or state should not silently determine the next outcome. Agree with the implementation team which component checks and complete workflows to automate.

Record version, environment, role and test data used. Keep actual results and findings separate from expectations; an unexecuted case remains open. Have the business owner assess deviations and repeat affected cases after a correction.

Sources

• GOV.UK: Writing user stories

• OWASP: Authorization checks

• Playwright: Best practices