Acceptance test are requirements and business rules.

Acceptance test are requirements and business rules.

We defined Agile user acceptance testing as a process that confirms that the output of a project meets the business’ needs and requirements. We described the incorporation of acceptance testing into a project’s Agile processes. A full understanding of Agile user acceptance testing requires a deeper understanding of what acceptance testing is, who is involved and the benefits.

Acceptance testing is known under many different monikers, including functional tests (older, from xP) to customer tests or customer acceptance tests. The use of the term customer reflects the inclusion of the product owner in the Scrum process. Mike Cohn dubbed acceptance tests as conditions of satisfaction, which brings the focus of acceptance tests to the needs of the customer/product owner. Acceptance tests provide a mechanism to verify and validate whether the delivered business functionality works based on the requirements and needs of the application’s stakeholders. This means the acceptance tests need to validate the delivered functionality and how that the functionality interacts the broader system environment.  Acceptance testing is generally black box testing, in other words, acceptance tests do not require an understanding of the structure of the code. The tester provides an input and receives an expected result, the person interpreting the test results does not care about how the result is generated.

In perfect world, product owners would craft the acceptance test cases as part of the user story.  The acceptance test cases reflect the requirements for the story and in many cases are the single version of the requirements. In this perfect scenario, the product owners would craft the acceptance cases and the developers would leverage them to build the production and then to prove completion. Because not all product owners will write acceptance tests, a more typical scenario is that a business analyst (or someone with those skills) will frame the acceptance test cases and then socialize them with the product owner and other developers. In many cases, I have leveraged a BA (singularly or as part of the Three Amigos) even when the product owner was willing to write the acceptance tests in order to ensure quality and consistency. A BA, because of their training in requirements development, will understand the need for format and granularity consistency. I generally do not use developers or user interface designers in this role, as their acceptance test cases tend to emulate integration tests rather than acceptance cases.

In Agile, capturing acceptance test cases as part of developing user stories provides the team with a significant number of benefits. The first benefit is that the process generates closer collaboration between the product owner and the team. Closer collaboration generates better requirements.  A second benefit is that that the acceptance criteria creates a contract for the team to determine when a story is complete at a functional level.  The overall definition of done defines completion at the process and standards level, while the acceptance tests provides the definition of completion at the story level.

The bottom line reason for a product owner or the Three Amigos to define acceptance test is increase the probability that a team will develop solutions that meet the organization’s needs and that what gets delivered actually works correctly the first time.  Higher customer satisfaction and fewer delivered defects is the best means to know whether your acceptance test process is on track.