Acceptance Criteria

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horseshoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.

capture the customer intent

Express criteria clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they will be taking our criteria and translating them into automated test cases to run as part of our continuous integration build.

Criteria should state intent, but not a solution.

Given some precondition When I do some action Then I expect some result I’ve found that using a verification checklist works well.

They are unique for each user story and define the feature behavior from the end-user’s perspective. Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.

scenario-oriented (Given/When/Then) rule-oriented (checklist) custom formats

This approach was inherited from behavior-driven development (BDD) and provides a consistent structure that helps testers define when to begin and end testing a particular feature.

User story: As a user, I want to be able to request the cash from my account in ATM so that I will be able to receive the money from my account quickly and in different places.

Acceptance criteria 1:

Given: that the account is creditworthy

And: the card is valid

And: the dispenser contains cash

When: the customer requests the cash

Then: ensure the account is debited

And: ensure cash is dispensed

And: ensure the card is returned

Acceptance criteria 2:

Given: that the account is overdrawn

And: the card is valid

When: the customer requests the cash

Then: ensure the rejection message is displayed

And: ensure cash isn’t dispensed

another format:

Example

User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.

Basic search interface acceptance criteria

The search field is placed on the top bar Search starts once the user clicks “Search” The field contains a placeholder with a grey-colored text: “Where are you going?” The placeholder disappears once the user starts typing Search is performed if a user types in a city, hotel name, street, or all combined Search is in English, French, German, and Ukrainian The user can’t type more than 200 symbols The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

Write testable AC. This will allow testers to verify that all requirements were met. Otherwise, developers won’t understand if the user story is completed.