QA glossary
What are acceptance criteria?
Acceptance criteria are the specific conditions a feature must meet before a product owner or client accepts it as done. Each one is a pass-or-fail statement written before development starts, so developers and testers work to the same definition of finished.
An example from QA practice
A user story reads: as a shopper, I can apply a discount code at checkout. Its criteria say a valid code lowers the total by the stated percentage, an expired code shows a message and leaves the total unchanged, only one code can be used per order, and the code field can be reached with the keyboard. A tester turns each line into test cases. A line that cannot be checked, such as "checkout should feel fast", is sent back and rewritten with a number.
Criteria are not test cases
Criteria say what must be true. Test cases say how to check it, with steps and data. One criterion usually produces several test cases, including the awkward ones: an empty field, a code typed in lower case, a second code added after the first. A common way to write criteria is Given, When, Then: given a basket over the minimum, when the shopper enters a valid code, then the total drops by the stated percentage.
Criteria also differ from a definition of done. The definition of done is one team-wide checklist applied to every story, such as code reviewed and tests passing. Acceptance criteria belong to a single story and describe its behaviour.
How BetterQA does it
BugBoard, the test management tool we built, links test cases to Jira tickets. A story with no linked test shows up as a gap before release, not after, so someone can check its criteria are covered.
Related terms
How acceptance testing runs once the criteria are written.