Acceptance Criteria (AC)
We use this to .... so that we can ....
These basically form the boundary or scope of your Story, if you will. Technically, anything that falls outside of the acceptance criteria is not to be built as part of the story.
ACs sometimes could have:
- Lo-Fi prototype (e.g. sketches, wireframes, etc.), Narrative, Context Diagram, Dependent Stories, Constraints.
And less often have:
- Technical Design, Data model, Consider points, Link to high-level scenarios, GUI design.
The ABCs of Acceptance Criteria
Abstract
A test is readable as a document describing system behaviour. Amplify your test's essential elements, and bury its irrelevant details and clutter. Anyone, including non-techies, should be able to follow the steps taken in the test and understand why it passes.
Bona fide
To ensure continual customer trust, a test must always truly exercise a system as close to production as possible. Passing acceptance tests tells the customer that what they asked for is complete and working.
Cohesive
A test expresses one goal accomplished by interacting with the system. Don't prematurely optimize by combining multiple scenarios into a single test.
Decoupled
Each test stands on its own, not depending upon or being impacted by results of other tests. A failure caused by problems in another test can be difficult to decipher.
Expressive
A test is comprehensible as documentation, not requiring research to understand. Name it according to the goal it achieves. As with unit tests, refactor each test to improve the ability of a third party to understand its intent. You should always eliminate magic numbers, replacing them with constants as appropriate.
Free of duplication
Eliminate duplication across tests (and even within the same test) before it eliminates you! Duplication increases risk and cost, particularly when changes to frequently-copied behaviour ripple through dozens or more tests. Duplication also reduces the use of abstraction, making tests more dense and difficult to follow.
Green
Once a story is complete, its associated ATs must always pass. A failing AT should trigger a stop-the-line mentality. Don't allow your test suite to fall into disarray by allowing failures to be ignored
Types of Acceptance Criteria:
Gherkin Reference (Given When Then)
Used when Behaviour/Scenario driven
Format
Scenario: <Name for the behaviour that will be described>
Given <Beginning state of the scenario>
When <Specific action the user makes>
Then <Outcome of the action in "When">
And <Used to continue any of the three previous statements>
E.g.
Rule Orientated
Used when we don't need details of test scenarios
Format
Simple bullet list
Custom
Used when the above formats don't cut it, we make up what makes sense and would be clear and useful for developers and testers
Format
E.g. Truth tables, wireframes, flow charts, etc.
Last updated