The short answer
A criterion is useful when two people, reading it separately, would agree whether the software meets it. If the answer depends on judgement, it is a preference and it needs converting into something observable before it is agreed.
The test is whether you could hand it to someone with no context and they could check it.
Turn opinions into observations
| Vague | Testable |
|---|---|
| The page should load quickly | Loads within 2 seconds on a 4G connection |
| Search should be accurate | Searching a full product code returns that product first |
| It should handle errors gracefully | An invalid card shows the reason and keeps the form filled |
| The report should be easy to read | The report fits one page and totals reconcile with the ledger |
| It should work on mobile | Every task completes on a 375px screen without horizontal scrolling |
The right column can be checked by anyone. The left column can be argued about indefinitely, usually on the day before go-live.
Cover the unhappy paths
Most criteria describe what happens when everything works. Most disputes are about what happens when it does not.
- What the user sees when a required field is missing
- What happens when an integration is unavailable
- What happens when two people edit the same record
- What happens when a file is too large or the wrong type
- What happens when the session expires mid-task
Writing these down takes an hour and removes most of the late surprises. They are also the cases that get skipped in testing unless someone has named them.
Include the non-functional ones
Performance, availability, browser support, accessibility and security requirements belong in acceptance criteria if they matter. Assumed requirements are discovered during acceptance, which is the most expensive moment to find them.
Be specific: which browsers and versions, what load, which accessibility standard. A requirement to be accessible without naming a standard is not testable.
Agree who signs
- Name the person who accepts, per area, before the build starts.
- Give them the criteria in advance rather than at the demo.
- Let them test in an environment with realistic data.
- Record what was accepted and when.
- Agree what happens when something fails: fix and re-test, or accept with a noted defect.
Acceptance without a named owner means everyone has a view and nobody decides, which is how sign-off drifts for weeks.
Keep them alive
Criteria written at the start describe what you knew then. When requirements change, update the criteria in the same conversation rather than leaving them to contradict the build.
Stale criteria are worse than none, because they give false confidence that something was agreed when it was quietly superseded.