02 / THE OUTCOME
Make the outcome something you can observe
Replace broad promises with a starting condition, a specific action and a result a reviewer can inspect.
“It works correctly” sounds reassuring because it avoids every disagreement. It does not say what happens, who can see it or what evidence would prove otherwise. An acceptance case needs enough detail to make those disagreements visible.
Given, When and Then offer a simple order for the discussion. Start with a relevant condition, name the event, then describe an observable result. The value comes from the decisions those sentences contain, not from the labels themselves.
Give each sentence a separate job
Cucumber’s Gherkin reference uses Given for context, When for an action or event, and Then for an expected outcome. Its guidance places outcomes at an observable boundary, such as a report or interface, rather than relying only on an internal implementation detail.
For the fictional reading list: Given the list contains two titled entries, When the reader saves and opens the file, Then both titles appear in the chosen order. The case leaves the storage library and download implementation open while making the promised result inspectable.
Given should not become a hidden second task. If the starting state takes ten unrelated steps to explain, extract the state that matters. A separate setup note can describe how a tester obtains it without making the actual acceptance condition unreadable.
Sources: Cucumber: Gherkin reference
Replace a judgment with a discriminating observation
A useful outcome rules out at least one plausible wrong result. “The export is correct” does not distinguish a missing title from a duplicate. “Both titles appear once each, in the displayed order” does. Someone can point to the evidence and explain why the result met or missed the condition.
Some outcomes need an explicit measurement context. “The response is quick” could become a timing requirement only after the team chooses a meaningful boundary, environment and way to measure it. Inventing a millisecond target to make the sentence look precise does not establish that the target is useful.
For subjective aims such as confidence or clarity, keep the desired experience and the evaluation method separate. A content inspection can check that a filename is visible. Learning whether people understand the filename may require an appropriate user study. Neither observation should be passed off as the other.
Describe failures with the same care as success
A failed operation still has an observable result. For an empty reading list, the example says the page explains that at least one entry is required and does not request a download. “Show an error” would leave the content and effect of that error unspecified.
GOV.UK’s error-message guidance recommends explaining the problem and how to fix it, and retaining entered answers. Use that advice as a source for discussion, then write the behavior your particular interaction requires.
For a field a person can correct, identify the field and the correction. For an unavailable external service, an instruction to change valid input may be misleading. Distinguish the kinds of failure before deciding whether the response belongs beside a field, in a page-level notice or elsewhere.
Sources: GOV.UK Design System: Error message
Keep proposed results separate from observations
Use different fields for expected result and actual observation. Before implementation, the actual-observation field is empty or not run. During a check, record what happened even if it differs from the expected wording. This separation prevents a beautifully written requirement from becoming imaginary evidence.
The downloadable outcome worksheet adds environment, version, evidence location and status. Those fields belong to the record of a real check. “Inconclusive” is useful when the setup failed or the evidence cannot resolve the question. It should not be silently converted to pass.
If a failure changes your understanding of the requirement, update the brief deliberately. Record whether the implementation was wrong, the expected result was wrong or both need discussion. Editing the expected result merely to match the current behavior conceals the decision.
Use the notation at the right level
Our builder exports prose with Given/When/Then labels, in Markdown or JSON. It does not create executable tests. Cucumber scenarios become executable through corresponding step definitions and a configured test runner; that implementation work is a separate task.
A team can keep plain acceptance prose even when it uses another testing framework. The key question is whether a reviewer can connect the goal, case and actual evidence. Avoid forcing an entire manual procedure into one sentence solely to resemble a familiar template.
Create a draft in the Acceptance Criteria Builder. The brief guide helps keep the goal attached, and the boundary guide helps choose which other examples deserve attention.
Sources: Cucumber: Gherkin reference