Key Sharing Points：
Summary of Acceptance Criteria
Characteristics of Acceptance Criteria
Examples of writing Acceptance Criteria
Backgrounds：
When we write a story, it always has at least one acceptance criteria attached to it (and if the story itself is written as though it were a happy path, those acceptance criteria can be the story itself). But stories usually have more acceptance criteria than just the happy path. Writing acceptance criteria makes your story ready for development. Key facts of Story Writing are listed as follows:
Priority
Acceptance criteria
Knowing what the end to end test scenario is /are
Sign off from the clients
An estimate from iteration based on all of the above
What is Acceptance Criteria：
Acceptance Criteria are a way of capturing the expected behavior of the system, written in such a way that we can easily test to see if they have been met.
A set of conditions that the story must meet for it to be accepted as complete
Described by the business – normally during the development phase
From Acceptance Criteria, we're able to get common understanding business requirements, user story exit criteria, a skeleton for test scenario and achievable development objectives.
Keep SMART in mind when defining acceptance criteria: Specific, Measurable, Achievable, Relevant, Time-boxed.
Characteristics of Acceptance Criteria
Acceptance criteria should be used to determine when a story is done. It should be clear enough to explain the steps taken to test the functionality and it must clearly define the intended outcome.
Readable
Acceptance Criteria can be fleshed out in 2 ways; Scenario style or Behavior Driven Development (BDD) style.
The Behaviour Driven Development approach allows us to set the context for each test condition. This approach helps tease out all possible conditions that can affect the story.
Given: that my mobile phone is switched on
And: I have sufficient signal to make a call
When: I dial a number
Then: I am connected to the person I want to talk to
And: incoming calls are diverted to my voicemail
Testable
Common issue: Using vague statements
Given: that I have the search page loaded
When: I perform a search
Then: the search results come back within a reasonable period of time
Improved version
Given: that I have the search page loaded
When: I perform a search
Then: the search results come back within 5 seconds
Strong Verb usage
Avoid weak verb forms like should and could– instead use absolute statements. For example: replace "the system should show x" with "the system displays x”.
Given: that I am logged into the system
When: I navigate to the search page
Then: an option to search based on the "Name" field should be displayed
Improved version
Given: that I am logged into the system
When: I navigate to the search page
Then: an option to search based on the "Name" field is displayed
Tell A Story
For complex stories where there are multiple acceptance criteria and exception cases, structure acceptance criteria in such a way that they walk the user through the scenarios in a realistic order with exception cases at the end.
Call Available number
Given: that my mobile phone is switched on
And: I have sufficient signal to make a call
And: the person I am calling is available on the network
When: I dial the number
Then: the screen display indicates that the phone is ringing
And: my incoming calls are diverted to my voicemail
Person answers call
Given: that I have dialed an available phone
And: the phone I am calling is ringing
When: they answer the call
Then: the screen display shows that I am connected
I end the call
Given: that I have dialed an available phone
And: the person I called has answered the call
When: I terminate the call
Then: the screen displays the fact that the call has ended
And: my incoming calls are no longer diverted to my voicemail
Example: Methods to writing Acceptance Criteria
Given the customer has one transaction account and one credit account
When they have completed logging in
ThenThen the screen should show the names and numbers of the two accounts sorted in account number order
Given the customer has just one transaction account
When they have completed logging in
Then the screen should show the name and number of the account
Given the customer has no accounts
When they have completed logging in
Then the screen should show a message stating that no accounts are available
Given the customer has more than 20 accounts
When they have completed logging in
Then the screen should show the first 20 accounts (in account number order) only
Given the customer has some accounts
And they have completed logging in
When the system cannot retrieve the account details
Then the screen should show an error message with associated code and details to contact for support
Thoughts:
Ensure that we have technical people in the room when discussing Acceptance Criteria. Acceptance Criteria is not a Narrative, not a Test, it is Understanding. Collaboration, communication to reach a shared understanding via this tool will drive great effectiveness.
Reference:
参考书目：《User Stories Applied: For Agile Software Development》 （中文名：用户故事和敏捷方法)
延伸阅读：项目管理中的敏捷实践
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
