5 exercises on Given/When/Then, definition of done, edge cases and measurable, verifiable outcomes.
Key patterns
Given = precondition, When = action, Then = observable outcome.
Cover the happy path and the edge / failure cases.
Each criterion must be measurable and independently verifiable.
Keep criteria atomic — one behaviour per statement, no “and”-chains.
0 / 5 completed
1 / 5
Which acceptance criterion is written correctly in the Given/When/Then format, with each clause in the right role?
Given = precondition, When = action, Then = observable outcome.
Option B maps each clause to its correct role:
Given a registered user on the login page — the starting state;
When they request a reset — the single triggering action;
Then a link is emailed within 2 minutes — a measurable, observable result.
Option A scrambles the roles: “a reset email is sent” is an outcome wrongly placed under When, and “has an account” is a precondition wrongly placed under Then. Option C is a user story, not a criterion — no verifiable outcome. Option D omits the Given and hides the result behind “works correctly”. Each clause should translate directly into a test step: Given = setup, When = the act under test, Then = the assertion.
2 / 5
A story is “As a user, I can upload a profile photo.” Which set of acceptance criteria best captures the definition of done, including edge cases?
Good acceptance criteria cover the happy path and the edges.
Option B specifies all three:
Happy path — JPEG/PNG up to 5 MB accepted and shown;
Edge / failure cases — oversized files and wrong types rejected with a visible error;
Side effect — a new upload replaces the old avatar.
The distractors lean on unfalsifiable phrases — “looks nice”, “reasonably robust”, “handle it appropriately” — that leave the failure behaviour undefined, which is exactly where bugs hide. A solid definition of done names the accepted inputs, the rejected inputs, the error messaging, and any state change. If a criterion can’t fail, it isn’t a criterion.
3 / 5
Which acceptance criterion is the most measurable — leaving no room for “is it done?” debate?
Measurable means a number a test can check.
Option C states a concrete latency budget (800 ms), a statistical target (p95), and a clear trigger (submitting a query). A performance test passes or fails against it with zero interpretation.
“Quickly”, “timely manner”, “good user experience”, and “don’t get frustrated” are subjective — two reviewers will disagree about whether they are met. When a criterion mentions speed, attach a threshold and a percentile; when it mentions size, attach a count; when it mentions accuracy, attach a tolerance. Useful collocations for measurable criteria: within X ms, at the 95th percentile, at least N results, no more than Z errors.
4 / 5
A reviewer says an acceptance criterion is “not independently verifiable”. Which rewrite fixes that problem?
Independently verifiable = anyone can check it without asking the author.
Option B describes outcomes that can be observed in concrete artefacts — the paid status on the order record and an entry in the mail log. A tester, a PM, or an auditor can all confirm it the same way.
“Integrate smoothly”, “feel seamless and modern”, and “good enough to ship” depend on opinion or on the author’s say-so — they fail the independence test. When writing a Then clause, point it at something inspectable: a database field, an API response, a UI element, a log line, an emitted event. If you can’t name where to look, the criterion isn’t verifiable yet.
5 / 5
Which is the best-scoped acceptance criterion — testing one behaviour rather than smuggling several into one line?
One criterion, one behaviour. Atomic criteria are easy to trace to a single test and easy to mark pass/fail.
Option B isolates exactly one rule: blank email → specific error message → submission blocked. That maps to one automated test.
Option A chains five behaviours with and; if four pass and one fails, the criterion’s status is ambiguous. Options C and D hide behind “correctly”, “as expected”, and “every possible input” — none of which can be enumerated, so they can never be proven done. Split compound behaviours into separate criteria (one for the blank-email case, one for invalid format, one for the success path). Each scenario becomes its own Given/When/Then, and your traceability stays clean.