I’ve found that the primary challenge in building software is, above all else, a communication problem. Someone needs to dream up what an application needs to do, and others need to build and test it. If there are communication issues along the way, that’s going to cost time.
By design, the “specifications” used in Scrum are very lightweight. Instead of attempting to create a comprehensive, all-inclusive written record of exactly what the application should do, user stories and acceptance criteria are used as stakes in the ground. Conversations among the Scrum team members take the place of the traditional software “spec,” using a collaborative approach to build the product to match the product owner’s vision.
Using acceptance tests is a highly effective way to increase the communication among the members of the Scrum team. Acceptance tests spell out a series of scenarios used to test the software. For example, if we’re building an e-commerce application and want to test the shopping cart, we’d have scenarios related to using a credit card, applying a coupon code, and adding and removing items.
Acceptance tests provide value beyond a simple test script:
- They let the product owner pre-visualize the behavior before it’s built. By using acceptance tests, the acceptance criteria can be expanded into specific scenarios, and the product owner can read through them and ensure the vision matches what’s in their head. If there is a mismatch—likely due to a communication problem—it can be identified when the scenarios exist “on paper” and before all the coding has been completed, at which point changes are more difficult, more time consuming and expensive.
- They allow beta testing user story acceptance criteria. To expand acceptance criteria into acceptance test scenarios, there must be a full understanding of the conversations that have taken place related to the story. If the author of the acceptance tests has trouble creating the scenarios, it’s typically because some part of the story is unclear.
- They provide specific examples for software developers. When developers are writing code and developing their own code-level automated unit tests, they can use acceptance tests as a shortcut. They can see a set of scenarios their code needs to support and can even use the specific examples as a foundation for their unit tests.
- They outline a game plan for testers. Last but certainly not least, acceptance tests form a plan for testers to use when they are testing a story’s coded functionality. They also form a foundation for discussions with developers about any bugs they find. “See here, Sally? It’s supposed to work like this.”One of the primary reviewers of acceptance tests is the product owner. This is one reason I find it’s important that tests are written in a format that’s simple and readable. I suggest using a behavior-driven development (BDD)-style format. It uses a standard “given, when, then” syntax that is easy to learn, compact, and simple.
The structure is as follows:
Scenario 1: [Title]
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
For example:
Scenario 1: Apply Coupon Code to Cart
Given there is a coupon code “DISCOUNT10”
And the code is configured as a 10% discount on the entire purchase
And I have $10 of items in my cart
When I enter the coupon code “DISCOUNT10”
And I apply it
Then the total price of the cart should be $9
And I should see an indication that the coupon code has been applied
This format allows expansion of the typical acceptance criteria-based structure I suggest for user stories.
When to Write Acceptance Tests
Because acceptance tests provide a lot of up-front value for a story, it’s helpful to get them written as quickly as possible.
Our Scrum teams try to write the unit tests early in the sprint, as the coding work begins on the first story or two. If there is an issue with a story being confusing or acceptance criteria incomplete, the product owner can address any issues early in the sprint, saving a lot of time.
Who Should Write Acceptance Tests?
Acceptance tests are a great target for leveraging the cross-functional nature of the Scrum team. The short answer as to who should write them is “Whoever is available.”
That said, I do have favorites. My number one favorite would be the QA specialist on the team. This type of person is typically really good at thinking through all of the “what ifs” related to a story, asking the hard questions of the product owner.
The ScrumMaster and even the developers can pitch in here and there, to help to get ahead on the writing or fill in when the QA person is unavailable. Even the product owner can help out with the writing, though I personally prefer to have them be the reviewer as opposed to the author. It’s nice to get a set of eyes, other than that product owner’s, on the acceptance criteria and think through the related test scenarios.
Finally, a software developer can absolutely write acceptance tests, though we typically find we get the best results by having the developers heads-down writing code at the beginning of the sprint.
The Product Owner Review
Though anyone on the team can review acceptance tests, I’ve seen the best results when the product owner reviews them.
With a review by the product owner, we get a tight feedback loop very early in the sprint, by having the product owner “see” the story’s acceptance criteria expanded into scenarios as the code is being written, or even before coding has begun. This helps identify problems early and helps to avoid issues when it comes time for the product owner to review the completed story.
Adopt the Acceptance Tests Technique for Your Scrum Team
A lot of people think agile is the wild west of software development, but that is not an accurate depiction. With a greater understanding of how to apply testing practices, agile has a much broader reach and has the potential to increase quality of your development projects. Acceptance tests are a simple way to document the vision of the as-built user story.
If you’re struggling to incorporate acceptance tests into your Scrum process contact us to learn more about how we’re helping teams improve agile delivery and the overall quality of shippable software increments.
