Write down how you will know a feature is finished.

Fictional requirement: approve a pending request. Describe the starting state, action and outcome: an authorised person opens REQ-01, selects approve and sees “approved” when reopening it.

Include persistence in the expected outcome. A button changing colour does not establish that the decision was saved. Check the data that matters to the process.

Describe missing permission, a request already decided and a failed save. In this exercise, an unauthorised person cannot approve, a resolved request shows its existing decision, and a failed save does not display false success.

Do not assume a mockup defines these behaviours. Agree on the message and the user’s next available action, then record them.

Copy: case identifier; initial state; person and permission; action; expected outcome; observed outcome; evidence; passed or pending. Use fictional data so the test can be repeated without affecting real work.

A screenshot can show a message, but reopening the request may be necessary to verify its state. Choose evidence according to the behaviour rather than convenience.

For this example, approval without permission blocks release. A wording improvement can be recorded separately if the responsible people accept it. Keep unresolved decisions visible.

Rerun affected cases after a correction. Do not close an issue merely because the code changed; check the outcome that prompted the issue.