How to Convert Acceptance Criteria to Test Cases

You wrote the user story, agreed the acceptance criteria in refinement, and the feature shipped. Two releases later, a support ticket shows that one of those criteria no longer holds. Nobody noticed, because nobody checked after the sprint review. This guide shows product managers how to convert acceptance criteria to test cases that run automatically before and after every release, so the behaviour you signed off stays true.

Most of the work is writing, not coding: making each criterion precise enough that a machine, or a new colleague, could decide pass or fail without asking you.

The problem: criteria that are checked once

In most teams, acceptance criteria live in the ticket. A developer reads them while building, someone clicks through them before the demo, the story is accepted, and the ticket closes. After that, nobody checks them again.

The behaviour still matters. A sign-up rule agreed in March is just as important in September, after the authentication library was upgraded and the form redesigned. Releases get signed off on what changed on purpose, while what changed by accident goes unexamined. It is one of the patterns in Common Release Mistakes in SaaS Products.

Acceptance criteria vs test cases

The ISTQB glossary defines a test case as a set of preconditions, inputs, actions, expected results and postconditions. Acceptance criteria are the conditions a piece of work must meet to be accepted. Atlassian's guide to acceptance criteria describes them as clear, concise and testable statements of the desired outcome, not of how to reach it.

	Acceptance criteria	Test cases
Answers	What must be true for the story to be accepted?	How exactly do we check one of those things?
Language	Business outcome, in plain words	Starting state, action, test data, expected result
Usually written by	Product manager or owner, with the team	QA, reviewed by product
Scope	One rule or behaviour	One path through that rule
How many	A handful per story	Several per criterion, including negative paths

The relationship is one-to-many. Atlassian's guide says each criterion should map to one or more executable tests. "Duplicate email addresses are refused" needs a case where the refusal happens and another showing that a new address is still accepted. For how scenarios, cases and steps relate, see Test Scenario vs Test Case.

Why it matters for release sign-off

When you accept a story, you vouch for its criteria. When you sign off a release, you implicitly vouch for every criterion that shipped before it, usually without current evidence.

Executable test cases change that. Sign-off moves from "the new features look right and nothing obvious broke" to "the new features look right, and every agreed behaviour we automated passed on this build". A failed check tied to a named criterion is also a precise bug report (this rule, this input, this result), which engineering can act on faster than "sign-up seems broken".

Common mistakes when writing acceptance criteria

Vague words. "Fast", "user-friendly", "intuitive", "handles errors gracefully". Two people will test these differently, and a machine cannot test them at all.

Describing the build, not the outcome. "Add validation to the email field" says what to build, not what the user experiences. Describe the result instead: "an address without an @ sign is rejected with a message under the field".

Only the happy path. What happens with an existing email, an expired link, a password one character too short? If the criteria do not say, each tester decides, and the product does whatever the code happens to do.

Several behaviours in one line. "User can sign up, verify their email and complete onboarding" is three criteria. When it fails, nobody knows which part broke.

Outcomes nobody can see. "The account is stored correctly" is invisible from the product. The Cucumber Gherkin reference says an outcome should be an observable output, not hidden internal state such as database records. Say what the user sees or receives.

No example data. "Passwords must be strong" is a policy. "Passwords shorter than 8 characters are rejected" is a criterion, and it suggests two test values at once: 7 characters and 8.

How to make acceptance criteria testable

A testable criterion has a defined starting point, a single action and an outcome anyone can observe. Atlassian's guide makes the same point: replace "the results page should look good" with a measurable statement.

Vague	Testable
Sign-up is fast	The "Check your inbox" screen appears within 5 seconds of submitting the form
Errors are user-friendly	An email already in use shows "An account with this email already exists" under the field
The email is sent	A verification email with a link arrives at the address used to sign up

Write from the user's point of view: what appears on screen, in an inbox or in a downloaded file. When a rule has a boundary, such as a length, an amount or a date, put the boundary value in the criterion so QA does not have to guess.

Two formats that work

Most teams use two formats, often in the same story.

Rule-based checklist

Short statements, each independently true or false: "Passwords shorter than 8 characters are rejected with an inline message." Checklists suit rules, limits and what a page must contain.

Given/When/Then

For behaviour that depends on a starting state or a sequence, a scenario is clearer. Martin Fowler's note on Given When Then describes the style, developed by Daniel Terhorst-North and Chris Matts as part of behaviour-driven development: Given is the state before the behaviour, When is the behaviour, and Then is the change you expect. In Introducing BDD, North describes a story's behaviour as simply its acceptance criteria, written in a format loose enough for analysts and structured enough to automate.

Scenario: New visitor signs up with a valid email
  Given no account exists for "signup-a@example.test"
  When the visitor signs up with that email and the password "Trial-pass-26"
  Then the "Check your inbox" screen is shown
  And a verification email arrives at "signup-a@example.test"

The Cucumber reference sums up each keyword: Given puts the system in a known state, When describes an action or event, and Then checks an observable outcome. That last rule matters most once a criterion has to run as an automated check.

How to convert acceptance criteria to test cases

With testable criteria, the conversion is close to mechanical. For each criterion:

1. Name the starting state. Who is the user, and what already exists? "No account for this email" and "an account already exists" are different cases.
2. State one action. Sign up, open the link, submit the form.
3. Choose test data on purpose. A valid value, an invalid one, and the values either side of any boundary.
4. Write the expected result as an observation: a message, a screen, an email.
5. Add the paths that should fail. For every rule that allows something, write a case where it is refused.
6. Mark what runs automatically. Anything repeatable with a clear pass or fail becomes an automated check. Anything that needs taste stays with a person.

Criteria that cross several screens, such as sign-up, verification and onboarding, become user flow testing: the cases run in order, and each one's output (a new account, an email) feeds the next.

A worked example

User story: As a new visitor, I want to create an account with my work email so that I can start a free trial.

Acceptance criteria:

1. AC1. Signing up with a new email address and a valid password creates an account, shows the "Check your inbox" screen, and sends a verification email to that address.
2. AC2. Opening the verification link signs the user in and shows the first onboarding step, "Name your workspace".
3. AC3. If an account already exists for the email address, sign-up is refused with the message "An account with this email already exists", and no email is sent.
4. AC4. Passwords shorter than 8 characters are rejected with an inline message, the entered email is kept, and no account is created.

Test cases:

ID	Criterion	Starting state and test data	Action	Expected result	Path
TC1	AC1	No account for signup-a@example.test (test inbox); password Trial-pass-26	Submit sign-up	"Check your inbox" shown; one verification email arrives	Positive
TC2	AC2	Continues from TC1	Open the email's link	Signed in; "Name your workspace" shown	Positive
TC3	AC3	Account exists for existing@example.test	Submit sign-up	Duplicate-account message; no email arrives	Negative
TC4	AC4	No account for signup-b@example.test; password Abc-123 (7 characters)	Submit sign-up	Inline password message; email still filled; no email arrives	Negative, boundary
TC5	AC4	No account for signup-c@example.test; password Abcd-123 (8 characters)	Submit sign-up	Accepted; "Check your inbox" shown	Positive, boundary

Four criteria became five test cases: two negative, two on the password boundary. Three details matter:

• Each case gets its own address. Reuse one email and TC1 passes only once; after that it quietly becomes TC3. Use test identities with their own inboxes, never a colleague's real email.
• "No email arrives" is a real check. It proves the refusal had no side effect.
• The boundary pair matters. TC4 alone would pass if the limit were accidentally 10 characters. TC5 proves it sits at 8.

Writing the cases also exposes gaps. Nothing here says whether the verification link expires, what happens if it is opened twice, or whether Existing@Example.test matches existing@example.test. Those are product decisions. Each becomes a new criterion or an explicit "out of scope" note: a cheap conversation before release, an expensive one after.

Who owns what between product, QA and engineering

• Product manager or owner: the story, the criteria, the examples and boundary values that make them concrete, and the decision to accept. They review test cases with one question: if all of these pass, am I convinced the story is done?
• QA: the expansion into test cases, negative and edge paths, test data, keeping checks current, and deciding what runs on every release.
• Engineering: testability (a stable staging environment, test modes for third-party services, a way to create test accounts), the unit and integration tests below the interface, and fixing defects when a check fails.

Atlassian's guide describes writing criteria as collaborative: the product owner usually starts the discussion, and the development team adds its view on feasibility and testability. Precise criteria written on day one are already most of the test.

Acceptance criteria, UAT and release sign-off

The ISTQB glossary defines user acceptance testing as a type of acceptance testing performed to determine if intended users accept the system. That covers two activities, and separating them answers a common question: can UAT be automated?

Checking agreed behaviour is repeatable and has a clear pass or fail. Does sign-up still refuse duplicate emails? Does the link still open onboarding? These checks need running on every release, and they can be automated. This kind of automated user acceptance testing is where converted criteria pay off.

Judgement is different. Is this step clear? Is it what we meant? Would a customer understand the error? No automated check answers those questions, and none should pretend to. That part of UAT stays with people.

A release then looks like this:

• Before release, the checks run against staging. A failure holds sign-off until it is fixed or the criterion is consciously changed.
• During acceptance, the product manager reads the run results instead of re-clicking every criterion, and spends the time on judgement calls.
• After release, the same checks keep running on a schedule, so a regression surfaces at the next run rather than in a support ticket.

Not every story needs permanent checks. Prioritise journeys that carry revenue, activation or trust; Critical User Journeys explains how to find them.

How AI changes the conversion

The slowest step used to be the last one: turning a reviewed test case into code that drives a browser. It needed an engineer, which is why many teams have good criteria and few automated checks.

Can ChatGPT generate test cases? A general chat model can draft test case text from a user story, and the draft is often a useful starting list. But it has not seen your live application, so it guesses at screens, labels and messages, and it does not run anything. Its output is still a document someone must execute by hand.

The useful step is turning each criterion into an executable check against the real application. Two things stay the same: a vague criterion still produces a weak check that passes while proving nothing, and a person still reviews what was generated. Our guide to writing test case generation prompts covers how to write the steps and the expected result.

Where BuniOD fits

BuniOD turns plain-language steps into a browser test, and a test case from the table above maps onto its input directly: the starting state and action become numbered steps, and the expected result stays the expected result. For TC1, the steps open sign-up, fill in the email from a test identity and the password Trial-pass-26, submit the form, wait a few seconds and confirm that "Check your inbox" is shown; the expected result is a verification email in that identity's inbox. BuniOD matches each step to an element on the live page and turns the prompt into a scenario with checks. You review and confirm it before it runs, and you can adjust input values or regenerate it from an updated prompt when the criterion changes. Because TC1 creates an account, a daily run needs a way to start fresh, such as deleting the account at the end of the flow.

Scenarios run in headless desktop Chromium, on demand or once a day at a time you choose. Each run keeps step and check results, screenshots, console and network logs, and an explanation of any failure. Test identities have their own inbox, so email checks work, and business processes run related scenarios in order. Criteria are entered as prompts, not imported from a tracker. The sign-up and onboarding testing page shows a worked example.

Conclusion

To convert acceptance criteria to test cases, start with the criteria: one observable outcome per line, no vague words, boundary values written in, and refused paths stated as clearly as successful ones. Each criterion then becomes a starting state, an action, test data and an expected result, and most of those cases can run automatically on every release.

Automated checks prove that agreed behaviour still holds; people decide whether it is what users need. A product manager who writes precise criteria has already done most of the work. The remaining step is making sure those criteria are checked after the sprint review, not only during it.