“I’m a project manager. Why do I need to know about automated acceptance testing? Isn’t that for the quality assurance people? Our user stories already have acceptance criteria – is this different?”
A project manager posed this series of questions to me. The project follows Agile practices by breaking down tasks into sprints and developing user stories with acceptance criteria. They have product owners who accept the final product. Most of their tasks are completed on time.
However, these tasks often reach their conclusion only to find out something has to be revised. Many of the projects are revised, re-scoped, and re-done after “completion.”
Sound familiar?
What is Automated Acceptance Testing?
Automated acceptance testing is a way for the team to better communicate about the acceptance criteria for a particular task. If you’re following Agile development, this is a way to clarify what needs to be accomplished.
For example, this is a user story for their mobile development task.
User story:
As a person visiting the website from my smartphone,
I want to view the webpage on my handheld device
so that I can get the information I want on the go.
Acceptance criteria:
The page should load nicely.
It should work on all smartphone devices
What does it mean for the page to load nicely? How does the product owner accept that? Does the product owner and the development team have the same definition of what it means to load nicely? The team might think about speed to load and responsive design to the size of the screen. The product owner might focus on the search box or call to action location.
How about working on a smart phone device? Which ones are there? How many have we considered?
Now, let’s revise the story using automated acceptance criteria written in Gherkin language.
User story:
As a person visiting the website from my smartphone,
I want to view the webpage on my handheld device
so that I can get the information I want on the go.
Acceptance criteria:
Given I go to the website on my <smart device>
When I open the page
Then the search box is displayed at the top
And the navigation menu displays below that.
The second example lays out clear, testable, measurable criteria.
It’s a team effort
Automated acceptance testing involves the entire team; it’s not just the responsibility of one team-member.
The product owner can determine the exact feature he or she is accepting. There is a better outline of the expectation with definable goals.
The development team has a clear understanding of the execution and on which tasks to focus. The team helps write the tests in conversation with the business analyst and product owner.
The business analyst and tester can structure tests better by writing clearer user stories with actionable testing criteria.
The project manager can ensure the right product gets delivered on time with limited rework.
What’s the Pay Off?
For website team used in this example, it means delivering complete tasks on time with the product owner’s approval and limited re-work.
The whole team is involved, and the whole team improves with this method, but the whole team might not buy-in immediately. It takes time to learn the new process, and it takes communication to work out a consistent understanding across your team.
The project manager needs to encourage the team to follow this method for the benefit of everyone. And for the project manager, it means less time in the long run trying to figure out why projects aren’t complete on time to specification.
Do you use acceptance testing on your development project? Have you had the same scenario given at the beginning?