03 / THE BOUNDARIES
Check the boundaries of a promise
Choose useful failure and edge cases, document the reason for each and keep untested risks visible.
The expected path explains the promise. A boundary case asks where that promise changes. A failure case asks what happens when an action cannot complete. Together they expose decisions that a single successful example can leave hidden.
You cannot list every possible input or event. The aim is to choose cases for a stated reason, preserve the gaps and decide what evidence matters for this change. A longer checklist is useful only when its rows answer distinct questions.
Locate the rule before choosing a number
Start with the rule that changes behavior. In our fictional reading-list brief, a proposed limit is 20 entries. That suggests checking the last allowed state and the first disallowed addition. It does not prove that 20 is the right limit; that is a separate product decision.
A boundary may be about more than a number. Consider an empty list, a repeated click, a permission changing during the task or an operation interrupted before completion. Write the specific condition and the part of the promise it threatens.
If no rule or risk explains a case, ask what you expect to learn from it. A random value might uncover something useful during exploration, but it is not automatically a boundary case. Keep exploratory notes distinct from the agreed acceptance conditions.
Pair refusal with preservation
For the twenty-first entry, a useful invented outcome is: the page explains the 20-entry limit and preserves the existing entries and order. The refusal and the preservation are both important. A page that rejects the addition but deletes the last valid entry has not met that outcome.
Ask the same question when an export fails: what work is still available afterward? A vague promise that an error appears may overlook the more costly result of losing the draft. In many workflows the valuable acceptance condition is the state that survives the failure.
GOV.UK’s error-message guidance distinguishes user-correctable input errors from service problems and advises keeping entered answers. Those are useful prompts when choosing cases, not a universal prescription for every interface.
Sources: GOV.UK Design System: Error message
Change one meaningful condition at a time
An example with an empty list, a disconnected network, a repeated click and an expired session may be hard to interpret. Begin with one meaningful change from the expected path. This makes it easier to explain which rule a result exercises.
Combined conditions can matter too. Add them because their interaction creates a plausible risk, and record that reason. For a browser-only text export, a network interruption may be irrelevant after the page has loaded. For an export generated on a server, the same interruption may be central. The architecture changes the question.
Avoid borrowing another product’s edge-case list without reading its assumptions. The Acceptance Criteria Builder offers case labels, but it does not know your product’s risks or decide which combinations are sufficient.
Write down the untested space
The case worksheet includes a reason, a proposed outcome and a coverage note. A coverage note can say “checks the entry-count rule only; does not cover unusual title characters or file encoding.” That sentence makes the evidence easier to reuse without exaggerating it.
Keep at least three statuses separate: planned, observed and unresolved. A proposed case is planned. A check with an environment and recorded result is observed. A question with no agreed expected outcome remains unresolved. Counting all three as completed tests would hide the remaining work.
Eight well-explained cases may teach more than eighty repeated happy-path examples, but neither number certifies completeness. Our builder’s eight-case cap is simply a drafting limit. Expand the record in your project tools when the risk calls for more detail.
Make the review a decision
Finish by identifying what happens next. The result might be ready for implementation within the named scope, held for a missing decision, or ready for a specific test in a defined environment. A brief can be useful while still being incomplete; its remaining questions should be visible.
Cucumber documents Scenario Outlines for running the same scenario with different example values. If you later automate a repetitive set, use the actual framework’s format and connect it to real assertions. The prose and JSON produced here are planning inputs; they have not executed anything.
Return to the observable-outcome guide when a case has no clear expected result. Use the brief worksheet when the cases have drifted away from the original user goal.
Sources: Cucumber: Gherkin reference