How to turn a user story into testable acceptance criteria
Acceptance criteria make a requirement observable: a reviewer should be able to determine whether the intended behavior is present. They help product and delivery teams agree on the boundary of a task.
Start with the right material.
- What you provide
- a visible user story with requirements.
- The intended result
- Save testable acceptance criteria with assumptions clearly separated.
How the workflow works.
Start from the explicit user need and describe relevant success and failure conditions. Separate criteria supported by the requirement from useful edge cases that still need the team's confirmation.
What to check in the result.
Check that each criterion can be evaluated without guessing the product decision. Unspecified values, such as an expiry duration or exact confirmation wording, should remain open rather than becoming invented requirements.
Preview the Markdown to check headings, lists and links as well as the words. Keep source references with the document so a reviewer can trace important statements back to the material you supplied.
Learn from the worked example.
The downloadable Markdown example shows one possible organization of the result. Read it alongside the source example and notice which statements are recorded facts, proposed wording or questions still needing an answer.
The supplied example is illustrative. It is not a recorded run on your data.
Download the example ↓Use it with your own material.
- Open the source you want to work with and activate WebAct on that tab.
- Copy the task from the hero, add any required fields or preferences, and review the proposed actions.
- Compare the first result with your source. Ask for a specific correction or refinement where needed.