Acceptance criteria

Acceptance criteria are a list of expectations that a user will have, when using a feature. They are written in short sentences to define a specific behavior of a feature, and they are commonly added to user stories to add more description.

Examples could be, the widget should have a text box and character count. Entering characters to reduce the character count could be another example. Or the third one is when character count is at zero, no more characters can be added to the text box.

It gives the team a boundary on what they should and shouldn't be delivering in a feature, and acceptance criteria, can help with discussion and collaboration of features. And acceptance criteria can help testers generate test ideas and identify risks.

Acceptance criteria can help stem testing ideas, but they are not tests themselves. And vague acceptance criteria can potentially lead to misunderstandings, and bugs in the system too.

Acceptance criteria are a list of points on a work item (often a documented as a ticket in a work tracking tool) that must be completed in order for:

It can be helpful to write acceptance criteria in a "given, when, then" format.  For example:
Given I'm not logged into the system,
When I navigate to the My Profile page,
Then I will be prompted to log in

Acceptance criteria can be used to generate testing ideas, and they can also be tested themselves.  Does the described behaviour make sense in context?  Is this really necessary in order to solve the problem?  Is the implementation method really crucial to the acceptance of this work item?

One of the best ways to write acceptance criteria is during a collaborative, story shaping meeting, such as Three Hats / Three Amigos or a refinement session, where people from different disciplines are present.  This will help the team to raise questions and concerns as early as possible.

Every requirement has boundaries, often called acceptance criteria. These criteria help to understand what the requirement covers, and what it doesn’t. Defining scope through acceptance criteria prevents wasted effort on unnecessary tests and keeps your focus sharp.

The specific, documented conditions a feature must meet for it to be considered complete and testable. In AI-assisted testing workflows, the quality of acceptance criteria directly determines the quality of AI-generated test cases: vague criteria produce confident-looking but incomplete tests, while detailed criteria enable the AI to generate meaningful coverage including edge cases. Acceptance criteria that cover OAuth flows, token behaviour, character limits, and error states, for example, will produce substantially richer AI output than criteria that simply state a feature should work.