From Acceptance Criteria to Test Cases: A Worked Example

“Let users archive projects” fits in a ticket title. It does not answer who can archive, where archived projects appear, whether their data survives, or what happens to running tasks.

Acceptance-test design turns that intent into agreed examples of observable behavior. The work starts by resolving decisions with the people responsible for the feature, then expressing cases precisely enough to execute and review.

This is part 13 of Testing Methods in Practice. The archive policy below is illustrative. It is not a claim about HiTest's project-management features.

Find the decisions hidden in the request

Ask who may archive a project, whether archived items are searchable, whether direct links remain accessible, and how restore behaves. Include existing data, active jobs, and workspace boundaries.

For this example, owners and editors can archive; viewers can read but cannot archive. Archiving retains content, moves the project out of the active list, and blocks new tasks. Running tasks must finish before archiving is allowed. Restore returns the project to the active list with its original content.

Use a short rule, example, and question map. An unanswered question should remain visible rather than being converted into the behavior the current code happens to implement.

Translate each rule into concrete examples

Open full size

Examples expose ambiguity. If a viewer can read archived projects, the direct-link case should say so. If the feature owner disagrees, resolve that rule before creating assertions.

Use Given, When, Then to express a decision

Scenario: Restore preserves an archived project's content
  Given an editor owns a test project containing two named documents
  And the project is archived
  When the editor restores the project
  Then the same project appears in the active list
  And both original documents can be opened after a reload

This scenario describes behavior without binding the rule to a button's position or a particular API implementation. Its setup still needs exact identities, roles, and fixtures in the executable case.

Cucumber describes BDD as a collaborative process for shared understanding and checked behavior. Writing Gherkin syntax alone does not establish that collaboration or make an ambiguous requirement complete.

Separate acceptance criteria from execution detail

The rule says an editor may restore. The browser instructions say how to sign in, choose the test workspace, open Archived, identify the project, and use Restore.

Keep incidental navigation in the execution steps. Preserve business decisions in the criteria. This lets the navigation change without silently weakening the expected behavior.

For browser execution in HiTest, write actions and expected visible results following manual test case creation. Keep server authorization and task-state invariants in the layer that can verify them directly. A visible restriction is useful evidence but does not replace server enforcement.

Review negative and interrupted examples

Add cases for a stale page, an expired session, and two people trying to archive and restore the same project. Do not add every combination blindly; identify which ones threaten the rules you just agreed.

For example, if a running task begins after the archive dialog opens, the server must recheck the rule at commit time under this policy. A dialog that was correct when opened can become stale before confirmation.

The decision-table guide helps with role and state combinations. The state-transition guide helps with archive, restore, and concurrent task states.

Make completion reviewable

Map every criterion to one or more cases. Record what was executed, against which build and environment, and what remains blocked. Keep illustrative examples separate from evidence of a real run.

If a criterion changes during development, update its examples and the affected tests together. A failing test should trigger a discussion about the rule or implementation; automatically changing the expectation to match the code removes the independent acceptance decision.

Your exercise: take a one-sentence feature request and list five unresolved questions. Agree on three rules, write one allowed and one denied example for each, and ask someone outside the implementation to predict the outcomes. Any disagreement is useful evidence that the specification needs another pass.

Next in the series: Choosing test layers.