Acceptance criteria: from requirement to check, Given/When/Then, and when you don’t need it

Acceptance criteria are written so there is nothing to argue about at acceptance. In practice they are exactly what gets argued about: each criterion allows two readings, and the case that matters is not on the list. The reason is almost always the same — the criteria were written as a retelling of the requirement, not as a check.

A retelling answers “what must the system do”. A criterion answers something else: “what will we do to confirm it does that, and what will we see”.

From requirement to check

A good way to write a criterion is to imagine it will be checked by someone who has read nothing but that criterion. What do they need to set up, what do they do, and what do they look at?

Requirement
  A customer can return an item within 14 days of delivery.

A retelling, not a criterion
  Returns are available for 14 days.

Criteria
  1. Order delivered 14 days ago → the “Return item” button is available
  2. Order delivered 15 days ago → no button; the order shows the date
     until which a return was possible
  3. Order not yet delivered → no button
  4. Days are counted from delivery, in the customer’s time zone

From the retelling you cannot tell whether day fourteen is included, which event the count starts from, or what the customer sees after the deadline. The criteria answer all of that — and each answer can be challenged before development rather than after.

Boundaries and negative cases

Most arguments at acceptance are about what is not in the criteria. Good criteria almost always contain three kinds of line:

• the main case — what the task is for;
• the boundary — the last value at which it still works and the first at which it no longer does (14 and 15 days);
• the negative case — when the feature must not trigger, and what the user sees then.

If the list contains only lines of the first kind, it describes the happy path. The rest will be decided by the developer and checked by the tester according to their own idea. Where to find the missing cases is covered in the piece on scenarios and exceptions: every scenario exception becomes at least one criterion.

Given/When/Then — and when it isn’t needed

The Given / When / Then format is good because it forces you to name the starting state. That is what criteria usually skip: “the button is available” — for which order, for which user?

Given   an order delivered 15 days ago
When    the customer opens the order
Then    there is no “Return item” button
  and   the line “Return was possible until 03.10” is shown

But the format is not the goal. It is awkward in three cases, and other forms work better there:

A table of examples for a calculation looks like this — and every row can be checked without asking the author a single question:

Refund amount
  price   discount          refunded before   refund
  1000    none              0                 1000
  1000    10% on order      0                 900
  1000    bundle BR-12      0                 per rule BR-12
  1000    none              400               600

Criteria, test cases and the Definition of Done

Three things that often get mixed up:

• Acceptance criteria — what must be true about this task. Written by the analyst, agreed by the product owner.
• Test cases — how exactly to check it: steps, data, environment. Written by the tester from the criteria.
• The Definition of Done — common conditions for any task: code reviewed, tests passed, documentation updated.

If criteria contain steps (“open the page, click the button, enter…”), that is a test case written by the analyst, and it will go stale with the first interface change. If the criteria say “covered by tests”, that is a line of the Definition of Done, not of this task.

Criteria are written before development. A criterion written afterwards describes what came out, and therefore always passes. It is the same mistake as a test written from the implementation in the piece on traceability, only at the level of the spec.

How many criteria are enough

There is no exact number, but there are two pointers. If there are more than a dozen, the task is probably several tasks and is worth splitting. If there is one, the task is either very small, or only the happy path was described.

The sign criteria are not working: at acceptance the tester asks the analyst “so how should it be” — and the analyst answers from memory rather than with a quote.

A ten-minute check

Take the criteria of a task about to go into testing. For each, answer: which starting state is needed, what is done, and what exactly is seen. Where there is no answer, the criterion needs finishing. Then count the boundary lines and negative cases. If there are none, those need writing too.

What next

Every criterion has a “Given” part — a starting state. An order delivered 15 days ago will not appear on the test environment by itself. Who prepares such data and how — and why everything works with it on staging and breaks in production — is the next piece.