Writing Good Acceptance Criteria
Behaviour Driven vs Procedural Driven Mindsets
Many of us may be used to writing/seeing procedural driven tests; step by step instructions with actions and expected results. Procedure-driven tests are often imperative and trace a path through the system that covers multiple behaviors. As a result, they may be unnecessarily long, which can delay failure investigation, increase maintenance costs, and create confusion.
Acceptance criteria, and indeed Behaviour Driven tests, should instead be behaviour driven.
This means they should be Declarative, specifying how a system should behave in a particular scenario.
Given the user opens a web browser And the user navigates to "https://localhost/mysite/"
Given a web browser is at the local home page
As a result of this declarative mindset, a behaviour should have a one to one relationship with scenarios, meaning we don't have multiple expectations of behaviour from a single scenario, which would be easy to do with the procedural mindset:
// BAD EXAMPLE - covers 2 scenarios When the user enters "cats" into the search bar Then links related to "cats" are shown on the results page When the user clicks on the "Images" link at the top of the results page Then images related to "cats" are shown on the results page
Given, When Then
Acceptance Criteria should be written in the Given, When Then format. The reason for this is that each of these steps has a specific purpose. Respect the order of these, if you move them around, the criteria may not be clear.
Given defines the prerequisites for the scenario, which screen we are on, and which data already exists. As it sets up state, it should be written in the present perfect tense, eg:
Bad: Given the Administrator navigates to the User Search page
Good: Given the Administrator is on the User Search page
When indicates the action being performed. It should therefore be written in the present tense, eg:
Bad: When the Administrator filtered the Users by name "Smith"
Good: When the Administrator filters the Users by name "Smith"
Then is the assertion, it verifies the new state that is a result of the When action.These are better written in the present tense, because using the future tense reinforces a procedure driven approach, treating the scenario as a time sequence.
Bad: Then users containing the name "Smith" will be shown on the results page
Good: Then users containing the name "Smith" are shown on the results page
Write full sentences
Subject - Predicate - Action
It may tempting to leave parts of speech out of a step line for brevity, especially when using Ands and Buts, but partial phrases make steps ambiguous. For example, consider the following:
// Bad Example Given the user navigates to the Google home page When the user entered "cats" at the search bar Then the results page shows links related to "cats" And image links for "cats" And video links for "cats"
Writing steps without a clear subject and predicate is not only poor English but poor communication.
Acceptance Criteria should cover the main scenarios which will be faced by the new functionality. They are not a full breakdown of test cases. Developers writing unit tests can cover edge cases and paths through the code, while QA can apply a broader, more exploratory approach to the new feature.
If you find yourself creating lots of different Acceptance Criteria, it might mean that the job needs to be broken down.
The Given, When, Then format may seem verbose, and all this talk of correct grammar might sound scary, but writing Acceptance Criteria this way is quite easy. Think of each Acceptance Criteria as an action with an expected result - and then add prerequisites (the "Given") only if required.
Use of the correct tenses is something that just comes with practice and is not super important, it just helps to prevent you falling back into the procedural mindset. It's more important to write full sentences and follow the Given/When/Then, or Prerequisites/Action/Expectation format.
Following this format sets a standard which all jobs can follow, bringing consistency and clarity to tasks. It ensures that the required expectations are met, and gets the team thinking about all the actions that need to be performed.