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.
As a Motor claims consultant
I want a TTD relating to fraud automatically generated against the claim lodged if claim could be fraudulent
So that I know that the claim needs to undergo further investigation in relation to fraud
AC01: When Motor claim is lodged via DISC and qualifies for fraud
GIVEN a Motor claim is being lodged in DISC
WHEN the 'Auto Fraud Score’ switch is On
AND fraud score is >= 100
AND claim is submitted
THEN the Auto Fraud Score TTD will be generated
AC02: When Motor claim is lodged via DISC and does not qualifies for fraud
GIVEN a Motor claim is being lodged in DISC
WHEN the 'Auto Fraud Score’ switch is On
AND fraud score is <100
AND claim is submitted
THEN the Auto Fraud Score TTD will be NOT generated
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
Was this helpful?