Acceptance criteria are the contract for a requirement. They state, before anyone writes code, what must be true for the work to count as delivered. Good criteria let a QA Engineer design tests without asking a single clarifying question. Weak ones get decided at the end, by whoever is holding the release.
This guide gives you a reusable template and three complete acceptance criteria examples, for login, payments and refunds. Each example shows the requirement, weak criteria and why they fail, improved testable criteria, and the failure, boundary and permission scenarios that most teams forget.
The one test every criterion must pass
Read the criterion and ask: could the system fail this? If you cannot describe a concrete behaviour that would fail it, you have written a preference, not a criterion. A criterion that cannot fail cannot be verified, so it will not be checked.
| Written | Can it fail? | Testable version |
|---|---|---|
| The interface should be intuitive | No. Nothing observable fails it. | A first-time user completes the flow without opening help. |
| Handle errors gracefully | No. "Gracefully" is unmeasurable. | On a timeout, the entry is kept and a retry option appears. |
| Search should be fast | No. "Fast" is unbounded. | Results return within 2 seconds for a catalogue of 100,000 items. |
| The export contains all active users | Yes. An export can miss one. | Already testable. |
A reusable acceptance criteria template
Copy this into your ticket or requirement. Fill in every section, even if the answer is "none": an empty section is a decision, a missing one is a gap.
STORY
As a <role>, I want <capability>,
so that <outcome>.
BUSINESS RULES
R1. <rule>
Status: confirmed / assumed
Ask: <owner>
R2. <rule>
Status: confirmed / assumed
Ask: <owner>
ACCEPTANCE CRITERIA
AC-01 Happy path
Given <context>
When <action>
Then <observable result>
AC-02 Failure
Given <context>
When <a dependency fails>
Then <safe result>
AC-03 Boundary
Given <value exactly at the limit>
When <action>
Then <result>
AC-04 Permission
Given <user without rights>
When <action>
Then <blocked, and how>
AC-05 Invalid input
Given <wrong or missing input>
When <action>
Then <result>
OUT OF SCOPE
<what this story does not cover>
OPEN DECISIONS
<question>
Owner: <name>
Needed by: <date>
Use it with the six paths that cover most late defects:
- Happy path. State it briefly. Everything else varies from it.
- Empty case. No data, first use, nothing selected.
- Boundary. What happens exactly at a threshold, not just either side.
- Invalid input. Wrong format or out of range, and what happens to what the user already entered.
- Failure. A dependency is down or slow, and whether the action is safe to retry.
- Permission. Someone without rights tries it. Blocked, and how.
Given, When, Then works best for behaviour with a real precondition, because it forces you to state the context, which is where ambiguity usually hides. For a plain data rule, such as "the report reconciles to the ledger to the penny", a single clear sentence is better.
The business rules in each example (L1, P1, R1 and so on) are illustrative assumptions added to make the criteria testable. In a real project, each one must be confirmed by the Product Owner before it becomes part of the acceptance criteria.
Example 1: login
Requirement: As a registered user, I want to sign in with my email and password, so that I can access my account.
Illustrative business rules: L1. After 5 failed attempts in a row, the account is locked for 15 minutes. L2. A signed-in session ends after 30 minutes of inactivity. L3. Users who have not verified their email cannot sign in. L4. Error messages never reveal whether an email is registered.
Weak criteria, and why they are unclear:
| Weak criterion | What is wrong |
|---|---|
| The user can log in | Restates the title. Says nothing about wrong passwords, lockout or sessions. |
| Login is secure | "Secure" is not observable. Which behaviour would fail it? |
| Show an error for invalid login | Which error? Does it reveal that the email exists? |
Improved, testable criteria:
- AC-01 Given a verified user with the correct email and password, when they sign in, then they reach their account home.
- AC-02 Given a wrong password, when the user signs in, then they see "Email or password is incorrect" and stay on the sign-in page.
- AC-03 Given an email that is not registered, when someone signs in, then they see the same message as AC-02 (rule L4).
- AC-04 Given 5 consecutive failed attempts, when a sixth attempt is made within 15 minutes, then sign-in is refused and the lock time is shown, even with the correct password.
- AC-05 Given an unverified email, when the user signs in, then sign-in is refused and a "resend verification" option is shown.
- AC-06 Given a signed-in user inactive for 30 minutes, when they take any action, then they are asked to sign in again.
Scenarios that are easy to miss:
| Type | Scenario |
|---|---|
| Boundary | The 5th failed attempt locks; the 4th does not. Sign-in succeeds at 15 minutes and 1 second, not before. |
| Boundary | Inactivity at 29 minutes keeps the session; at 30 minutes it ends. |
| Failure | The identity service is unavailable: a clear message is shown and no attempt is counted toward the lock. |
| Permission | A locked account cannot be unlocked by the user signing in again; only waiting or a reset works. |
| Invalid | Empty email or password: the form is not submitted and the field is highlighted. |
Example 2: card payment
Requirement: As a customer, I want to pay for my order by card, so that my order is confirmed.
Illustrative business rules: P1. The amount charged equals the order total including tax. P2. A declined card leaves the order unconfirmed and the basket unchanged. P3. If the payment provider does not respond, the customer is never charged twice. P4. Card details are never stored by us. P5. Only the order's owner can pay for it or view its payment.
Weak criteria, and why they are unclear:
| Weak criterion | What is wrong |
|---|---|
| Payment works | Unfalsifiable as written. Works for which cards, amounts and failures? |
| Handle payment failures | Which failures, and what does the customer see? |
| Payment is fast | Unbounded, and not usually what matters most. |
Improved, testable criteria:
- AC-01 Given an order with a total including tax, when the customer pays by card and the payment is approved, then exactly that amount is charged and the order shows as confirmed.
- AC-02 Given a declined card, when the customer pays, then the order stays unconfirmed, the basket is unchanged and the decline reason is shown.
- AC-03 Given a payment request with no response from the provider within the timeout, when the customer retries, then the customer is charged at most once.
- AC-04 Given a successful payment, when anyone inspects our stored data, then no full card number or security code is present.
- AC-05 Given an order that belongs to another customer, when a customer tries to pay for or view its payment, then access is refused.
Scenarios that are easy to miss:
| Type | Scenario |
|---|---|
| Boundary | The smallest and largest amounts the provider accepts; an order total exactly at the limit. |
| Failure | The provider times out, then approves late: the order is confirmed once, and the customer is charged once. |
| Failure | Double click on "Pay": only one charge is created. |
| Permission | A signed-out user opens a payment link for someone else's order: refused. |
| Invalid | Expired card or wrong security code: a specific message, and the rest of the form is kept. |
Example 3: refund request
This is the same refund example used in the guide to choosing a requirements management tool, with the same rules and criteria, so you can follow it across both guides.
Requirement: As a customer, I want to request a refund for a card payment, so that I get my money back for an order I no longer want.
Illustrative business rules: R1. Refunds can be requested within 30 days of delivery. R2. The refund goes back to the original card only. R3. A customer can refund only their own orders. R4. An order that has already been fully refunded cannot be refunded again. R5. Refunds above a configured amount need approval from a support agent; refunds at or below that amount do not.
Weak criteria, and why they are unclear:
| Weak criterion | What is wrong |
|---|---|
| Customers can get refunds easily | "Easily" is not observable, and it says nothing about limits. |
| Refunds are processed correctly | Correct to where, how much, and by when? |
| Old orders cannot be refunded | How old? What happens on the last allowed day? |
Improved, testable criteria:
- AC-01 Given a delivered order within 30 days, when the customer requests a refund, then a refund request is created and the customer sees its status.
- AC-02 Given an order delivered more than 30 days ago, when the customer requests a refund, then the request is refused with the reason shown.
- AC-03 Given an approved refund, when it is processed, then the amount is returned to the original card and not to any other method.
- AC-04 Given an order that belongs to another customer, when a customer requests a refund, then the request is refused and no order details are revealed.
- AC-05 Given a fully refunded order, when a refund is requested again, then it is refused.
- AC-06 Given a refund above the configured amount, when it is requested, then it waits for support agent approval before processing.
Scenarios that are easy to miss:
| Type | Scenario |
|---|---|
| Boundary | Day 30 after delivery is allowed; day 31 is refused. Decide whether "day" means calendar days in the customer's time zone. |
| Boundary | An amount exactly at the approval threshold is processed without agent approval under R5; the smallest amount above it waits for approval. |
| Failure | The payment provider rejects the refund: the request shows as failed, no money is recorded as returned, and support is alerted. |
| Permission | A support agent can approve; a customer cannot approve their own refund. |
| Invalid | The original card has expired: an open decision for the Product Owner, since R2 allows only the original card. |
Key takeaways
- If you cannot describe how the system could fail a criterion, it is a preference, not a criterion.
- Write the failure, boundary and permission cases on purpose; that is where late defects come from.
- Label every business rule as confirmed or assumed, and give each open decision an owner.
- Number criteria (AC-01, AC-02) so each test can name the criterion it verifies.
Acceptance criteria vs definition of done
Both decide when work counts as finished, which is why they get confused. They answer different questions.
Acceptance criteria belong to one story. They state the behaviour that story must show, and they change from story to story. AC-02 in the refund example, a request more than 30 days after delivery is refused with the reason shown, is true of the refund story and nothing else.
The definition of done belongs to the team. It is one shared quality bar applied to every story, for example code reviewed, tests passing, documentation updated and deployed to the test environment. It rarely changes from one story to the next.
A story is finished when it meets both: its acceptance criteria show it does the right thing, and the definition of done shows it was built to the team's standard. If the same line appears in every story's criteria, it probably belongs in the definition of done instead.
Common mistakes worth avoiding
Describing the implementation. "A dropdown appears in the top right" locks the solution and hides the need.
Restating the title. "The user can reset their password" adds nothing. Say what happens with an expired link or a second request.
Too many criteria on one story. Fifteen criteria usually means several stories. The criteria show you where to split.
Writing criteria after the build. At that point they describe what was built instead of agreeing what should be.
How ReqLens turns a rough requirement into testable criteria
Writing robust acceptance criteria requires careful analysis. ReqLens gets you to a reviewed first version from the one-line requirement, and keeps a person in charge of every decision.
1. Elaborate the rough requirement. Paste the one-line refund story into Requirement Studio. ReqLens produces a structured requirement with context, scope, actors, risk and a set of proposed acceptance criteria. An input-quality note tells you how much it had to work with, for example that a draft built from minimal input needs careful review.
2. See what is missing, as decisions. ReqLens lists coverage gaps, grouped by theme such as failure behaviour, actor and access, and business rules. Each gap states the scenario, the risk, its severity and the decision someone needs to make. For the refund story, that is where questions like the refund window, the payment method and who can approve surface, the same questions R1 to R5 answer above.
3. Review flagged criteria. A criterion that is vague or untestable carries a review flag: the issue, a suggested fix and a severity. The Product Owner accepts the flag, edits the criterion, or records a note explaining why it stands.
Criterion: "Refunds are processed correctly." Issue: not observable; no amount, destination or timing is stated. Suggested fix: state where the money goes and how much, for example "the approved amount is returned to the original card". Severity: high.
4. Approve, then carry the criteria into testing. Nothing is applied to your project until a person reviews it. Approved criteria keep their numbers, and TestCraft generates test cases linked to each one, so AC-02 has tests for day 30 and day 31 and you can see exactly which criteria are covered. The test case generation guide shows that step.
How you know your criteria are good
Hand the requirement to a QA Engineer and see whether they can design coverage without coming back with questions. If they can, the criteria did their job. If they return with five questions, those were about to become five silent assumptions in somebody's code. To review the whole requirement, not just its criteria, use the requirement quality checklist.
If you are choosing tools for this workflow, the requirements tool evaluation checklist helps you test how well each one supports it. To see how ReqLens connects criteria to tests, results and defects, read about ReqLens requirements management software, or compare ReqLens plans.