We have several activities that add layers of quality to our software development projects. These activities include unit tests, sprint code reviews, and test plans.
Recently, we added another quality layer to our process: acceptance test criteria. This new step occurs at the development story level before any coding begins. The goal is to ensure the whole team is on the same page regarding what is expected on this project.
How It Works
The development team participates in this exercise. For us, this includes the senior software architect, software architects and engineers, the quality assurance engineer, and the product manager/project manager. We gather to review each story and ask the question, “What functionality/behaviors must exist for this story to be considered complete?”
As the team responds, the project manager records what the team agrees to. Azure DevOps provides a place to enter acceptance test criteria on each story, so we’re able to create a bullet list that details the functionality expected. Each story only requires, on average, less than five minutes worth of discussion.
When we first used this process, the benefits of this added layer of quality were apparent:
- The entire team gets on the same page at the beginning of the project for the functionality to be developed
- New/missed requirements were uncovered through our discussions. This has happened in almost all of these exercises I’ve participated in
- Developers have criteria to follow when implementing/testing their code
- Our QA team has a guide to follow when creating their test plan
Adding the acceptance test criteria to our process came from a situation where an old project was brought back to life, and I needed to get the team back up to speed. Most of the project had already been defined over a year ago, so I saw this as an excellent opportunity to review the backlog and get everyone on the same page.
After going through this acceptance test criteria exercise, the benefits were so substantial that we are adopting it as a standard. Gaining a shared understanding of a project, its goals, and desired outcomes is key to how we build software systems, so this new process fits right in.