Module 5 · Requirements & static testing

Acceptance Criteria

By the Mutqan Soft QA team · Updated 6 October 2026 · 19 min · Beginner

Acceptance criteria are the conditions that an implementation of a user story must meet to be accepted by its stakeholders. The ISTQB Foundation syllabus adds the view that matters most to a tester: acceptance criteria can be seen as the test conditions that the tests should exercise. They usually come out of the Conversation, the second of the three Cs from the lesson on user stories, and once written down they are the third C, the Confirmation.

Take the story "As a library member, I want to renew a borrowed book online, so that I can keep it longer without visiting the library." It names the need, but not how much longer, how many times, or what happens when someone else is waiting for the book. Criteria such as "A renewal moves the due date 14 days later" and "A book reserved by another member cannot be renewed" answer those questions, and each can be checked with a clear pass or fail.

Why it matters

The syllabus lists what acceptance criteria are for: defining the scope of the story, reaching consensus among stakeholders, describing both positive and negative scenarios, serving as the basis for acceptance testing of the story, and allowing accurate planning and estimation. Without them, everyone fills the gaps with their own assumptions, and the difference often shows up only at the sprint review, when the work has to be redone.

For a tester, acceptance criteria are the first source of expected results. An expected result you invented is a guess about what the business wanted; one taken from an agreed criterion can be judged by anyone. Reviewing criteria before development is also static testing at its cheapest: a vague or contradictory criterion corrected in refinement never turns into a defect in the code.

Rule-oriented and scenario-oriented criteria

The ISTQB syllabus names two common formats. Rule-oriented criteria are a bulleted verification list, or a table that maps inputs to outputs. Scenario-oriented criteria are concrete examples in the Given/When/Then format used in behaviour-driven development (BDD). A team may use a format of its own instead, as long as the criteria are well defined and unambiguous.

The formats work together. Rules state a policy compactly and are easy to review for gaps; scenarios show the policy working on real data and remove doubt about what a rule means. Many teams write the rules first and add a scenario for any rule that could be read two ways. Gherkin, the language of the Cucumber tool, even has a Rule keyword that groups the scenarios illustrating one business rule.

A rule list suits limits, permissions, validations and calculations, such as "at most 2 renewals per loan".
An input-output table suits a rule with several conditions, where every combination needs an answer.
Scenarios suit behaviour that depends on state or on the order of events, and examples the team plans to automate.

LIB-42  Renew a borrowed book online
As a library member, I want to renew a borrowed book online,
so that I can keep it longer without visiting the library.

Acceptance criteria (rule-oriented)
AC1  A renewal moves the due date 14 days later, counted from the
     current due date, not from the day of renewal.
AC2  A loan can be renewed at most 2 times. My loans shows the renewals left.
AC3  A book reserved by another member cannot be renewed: the message
     "Reserved by another member" is shown and the due date is unchanged.
AC4  An overdue loan cannot be renewed online: the message
     "Overdue loans can be renewed at the desk only" is shown.

Anatomy of a Given/When/Then scenario

A scenario is one example of one behaviour. Given describes the context: the state of the system and its data before anything happens. When describes the event or action under test. Then describes the expected outcome. And and But continue the keyword before them, so an And after a Given adds context and an And after a Then adds another outcome.

Two habits keep scenarios useful. Use a single When step per scenario; needing a second one usually means you are describing a second behaviour and should split the scenario. And make each Then an observable outcome: Cucumber’s Gherkin reference asks for something that comes out of the system, such as a report, the user interface or a message, not a behaviour buried inside it, such as a record in a database.

Write the context as facts, not clicks. "Given Sara has borrowed Desert Stars, due on 10 March 2026" stays true when the screens are redesigned; "Given Sara opens My loans and clicks the first row" does not, and it hides which data matters. When one behaviour needs several data sets, a Scenario Outline runs once per row of its Examples table, as in the renewal limit below.

The LIB-42 renewal scenario taken apart: Given and And set the context, a single When renews the loan on 5 March, and Then states the visible results that become the expected results.

Test T1 of story LIB-42 written as a scenario

Part 1:1Scenario: Renewing moves the due date 14 days later
  Part 2:2Given Sara has borrowed "Desert Stars", due on 10 March 2026
  Part 3:3And nobody has reserved the book
  And Sara has not renewed this loan before
  Part 4:4When Sara renews the loan on 5 March 2026
  Part 5:5Then the due date shown on My loans is 24 March 2026
  Part 6:6And My loans shows 1 renewal left

2–3Context → the preconditions and test data of the test case
4Action → the test step and its input
5–6Outcomes → the expected results

1Scenario titleNames one behaviour: the rule from AC1 that this example illustrates.
2Given: the contextThe state before the action, written as facts with concrete data: who, which book, which due date.
3And: more contextRules out a reservation and earlier renewals, so that neither AC3 nor the renewal limit can change the result.
4When: one actionThe single event under test. Renewing on 5 March gives 24 March if days count from the due date, 19 March if they count from today.
5Then: the observable outcomeWhat the member sees on the page decides pass or fail, not a record in the database.
6And: a second outcomeAnother visible result of the same action: the renewals left that AC2 requires on My loans, which is why T1 is traced to AC1 and AC2.

Scenario Outline: A loan can be renewed at most 2 times
  Given the loan of "Desert Stars" to Sara has been renewed <before> times
  And nobody has reserved the book
  When Sara renews the loan
  Then the renewal is <result>

  Examples:
    | before | result   |
    | 0      | accepted |
    | 1      | accepted |
    | 2      | refused  |

Try it: Acceptance Criteria Generator

Good and bad acceptance criteria

A good criterion lets a product owner, a developer and a tester reach the same verdict on the same result. These checks catch most weak criteria, and the pairs below show the usual repairs.

Testable: an observable result with a clear pass or fail. "Renewing is easy" has neither.
Specific: numbers, limits, messages and roles are stated, not implied.
About behaviour: what the user experiences, not which table, field or API the developer changes.
Complete: the refusals are covered, including what the user sees when an action is not allowed.
Focused: one rule per criterion, so a failed test points at one rule.
Within the story: a condition that needs another feature belongs to another story.

Weak:     The renewal should be quick.
Testable: The new due date is shown within 2 seconds of selecting Renew
          (the value is for the product owner to confirm).

Weak:     The member can renew a book.
Testable: Each renewal adds 14 days to the current due date.
Testable: A loan can be renewed at most 2 times.

Weak:     Errors are handled properly.
Testable: A reserved book cannot be renewed; the message
          "Reserved by another member" is shown.

Weak:     The renew_count column is incremented.
Testable: The renewals left on My loans go down by 1.

Try it: AI Acceptance Criteria Reviewer

From criteria to tests: an introduction to ATDD

Acceptance test-driven development (ATDD) is a test-first approach: test cases are created before the story is implemented, by people with different perspectives, such as customers, developers and testers. It starts with a specification workshop, where the team analyses the story, writes any criteria still missing and resolves gaps, ambiguities and defects. Some teams call this meeting the "three amigos".

The test cases are then derived from the criteria. They are examples of how the software should work, which is why ATDD uses "examples" and "tests" almost interchangeably. The syllabus suggests an order: positive cases first, then negative cases, then non-functional characteristics such as performance efficiency or usability. The tests should cover every characteristic of the story without going beyond it, and no two tests should describe the same characteristic. The tests may be run manually or automated: written in a format an automation framework can run, they can be automated while the feature is built and become executable requirements.

Given becomes the preconditions and test data of the test case.
When becomes the test step and its input.
Then becomes the expected result, written down before the test is run.
Each test is traced to the criterion it checks, so you can report which criteria are covered.

Worked example: tests for the renewal story

In the specification workshop for LIB-42, the tester reads each criterion with the checks above and proposes test data. AC1 already says the 14 days count from the due date, yet a developer could still count from today, so the tester picks data that tells the two readings apart: a loan due on 10 March and renewed on 5 March must move to 24 March, while counting from the renewal day would give 19 March.

The tests follow the syllabus order: the positive cases T1 and T2 first, then the negative cases T3 to T5. Each Given rules out the refusals the test is not about, such as a reservation or an overdue loan, so that only one rule can decide the result. Each test is traced to its criterion, and each expected result was agreed before any code was written.

Open question Q1: AC2 does not say what the member sees when the limit is reached, so T3 cannot state a message yet. The product owner decides; the tester records the question on the story.
Open question Q2: a loan can be overdue and reserved at the same time. Which message is shown? The answer becomes a new criterion and a new test.

LIB-42 tests (positive first, then negative)

T1  AC1, AC2  Given: due 10 Mar 2026, no renewals yet, not reserved
              When:  renew on 5 Mar 2026
              Then:  due date 24 Mar 2026; renewals left: 1
T2  AC1, AC2  Given: due 24 Mar 2026, renewed once, not reserved
              When:  renew on 20 Mar 2026
              Then:  due date 7 Apr 2026; renewals left: 0
T3  AC2       Given: renewed twice, not overdue, not reserved
              When:  renew
              Then:  refused; due date unchanged (message: see Q1)
T4  AC3       Given: no renewals yet, not overdue, reserved by another member
              When:  renew
              Then:  "Reserved by another member"; due date unchanged
T5  AC4       Given: due 10 Mar 2026, today is 12 Mar 2026, no renewals, not reserved
              When:  renew
              Then:  "Overdue loans can be renewed at the desk only"

Try it: User Story → Test Cases Try it: Requirements → Test Cases

Common mistakes

Using words nobody can measure, such as "fast", "easy", "properly" or "user-friendly". Ask for the number or the observable result instead.
Writing only the happy path. Every limit, permission and refusal needs a criterion that says what the user sees.
Describing clicks and screens instead of behaviour, so the scenarios break with every redesign and hide which data matters.
Putting several behaviours in one scenario, with a chain of When and Then steps. When it fails, nobody knows which rule broke.
Treating criteria as fixed text the tester receives. They are agreed in conversation, and a tester who only reads them misses the cheapest moment to find defects.
Changing a criterion during the sprint without telling the team, so the code and the tests are built against different versions.

The QA perspective

Your biggest contribution happens before any code exists. In refinement or the specification workshop, read every criterion and ask "how would I test this?" and "what happens if…?". Propose concrete examples and test data, flag vague words, and suggest the missing negative criteria. The product owner decides the business rules; your job is to make sure the decision is written in a form everyone can check.

Record the agreed criteria on the story itself, with the open questions, their owner and a date. Link every test to the criterion it checks, and note which ones are automated. When a criterion changes during the sprint, update its tests in the same change. At the sprint review, show the evidence criterion by criterion, so that acceptance is a check, not a debate.

Practice exercise

Repair the criteria of a delivery-address story

Your task

A grocery app has this story and draft criteria. Find what makes each criterion weak, rewrite them as testable rules, then write two Given/When/Then scenarios and the list of tests you would derive.

Where a value is missing, propose one and mark it as a question for the product owner instead of deciding it yourself.

Material

GRO-17  Change the delivery address of an order
As a customer, I want to change the delivery address after placing an order,
so that the order reaches me where I will be.

AC1  The customer can change the address easily.
AC2  Changes should be possible until the order is far along.
AC3  Invalid addresses are handled properly.
AC4  The update must be fast.

Steps

Mark every word or phrase that two readers could interpret differently.
Rewrite the criteria as a rule-oriented list, one rule per criterion, with the refusals included.
Write one positive and one negative scenario in Given/When/Then, with concrete data.
List the tests you would derive: positive first, then negative, each traced to a criterion.

Show the model answer

Model answer

Weak spots: "easily" has no observable result and only restates the story; "should" leaves open whether the rule is mandatory; "far along" names no order status; "invalid" and "handled properly" say neither which addresses nor what the customer sees; "fast" has no number.

Rules, with the proposed values marked as questions. AC1: while the order status is "Preparing", the customer can replace the delivery address on the order page, and the order then shows the new address. AC2: from the status "Out for delivery" on, the change option is not shown, and a change sent through the API is refused (question: is "Preparing" the right cut-off?). AC3: an address outside the delivery zone is refused with the message "We do not deliver to this address", and the old address is kept (question: which other addresses count as invalid, for example one without a building number?). AC4: the new address is shown on the order within 2 seconds of saving (question: confirm the value, or cover it with a team-wide performance criterion).

Positive scenario: Given order 5531 has the status "Preparing" and the address 12 Palm Street; When the customer changes the address to 40 Garden Road; Then the order page shows 40 Garden Road. Negative scenario: Given order 5531 has the status "Out for delivery"; When the customer opens the order page; Then no option to change the address is shown.

Tests: T1 change while "Preparing" (AC1); T2 option hidden when "Out for delivery" (AC2); T3 change through the API refused when "Out for delivery" (AC2); T4 address outside the zone refused with the message, old address kept (AC3); T5 the 2-second limit, once confirmed (AC4), last because it is non-functional. One more question for the workshop: if the new address lies in a zone with a different delivery fee, what happens to the fee?

Frequently asked questions

Do acceptance criteria have to be written as Given/When/Then?

No. The ISTQB syllabus names rule-oriented and scenario-oriented as the two most common formats and accepts a custom format, as long as the criteria are well defined and unambiguous. Gherkin syntax is needed only when a BDD tool such as Cucumber will run the scenarios.

Who writes the acceptance criteria?

Usually the product owner or a business analyst drafts them, and the team refines them in conversation. The business decides the rules, developers check feasibility, and the tester makes each criterion testable and adds the negative cases. In ATDD they are completed together in the specification workshop.

What is the difference between acceptance criteria and test cases?

A criterion states a condition the story must meet; a test case is a concrete check of it, with preconditions, inputs and an expected result. One criterion usually needs several test cases, for example its positive case, its refusals and its boundaries.

How do ATDD, BDD and TDD differ?

All three write tests before code. TDD works at the level of code: a developer writes a failing unit test, then the code that makes it pass, and then refactors. ATDD derives acceptance tests from the acceptance criteria with the whole team before the story is implemented. BDD expresses the desired behaviour as Given/When/Then examples in natural language that stakeholders can read, often run with a tool such as Cucumber.

References

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
Gherkin Reference — CucumberCucumberThe Gherkin syntax for executable specifications: Feature, Rule, Scenario, Given/When/Then steps, Background, Scenario Outline and Examples.
Behaviour-Driven Development — CucumberCucumberBehaviour-Driven Development as three practices — discovery, formulation and automation — built on concrete examples that business and technical people agree on.