In software development, we can create an elegant solution. But if it doesn’t do what the business wants, we have essentially created a worthless solution. If the requirements and acceptance criteria are clear and concise, you increase your chances of delivering the right solution. Implementing acceptance testing to validate that we’ve built the right thing […]
In software development, we can create an elegant solution. But if it doesn’t do what the business wants, we have essentially created a worthless solution. If the requirements and acceptance criteria are clear and concise, you increase your chances of delivering the right solution. Implementing acceptance testing to validate that we’ve built the right thing leads to a quicker turn around on deployment, fewer bugs, and better quality.
There is a distinction between building the right thing and building the thing right. The latter involves practices such as test-driven development (TDD), behavior-driven development (BDD), continuous integration (CI), and automated deployments. It involves scaling and maintenance.
Building the right thing involves validating that the solution delivered satisfies the business requirement. One way to do this is through acceptance testing. These tests provide clarity of requirements, a manual for testing, and a path to automation. To better explore this, let’s examine one customer example.
This customer is rebuilding a legacy system in a C# framework. The first phase reached the end of development but had no automated acceptance test (AAT). When anything broke, it was a scramble to get it fixed. The approach involved three steps:
Once the client and team saw the demonstrated value of implementing automated acceptance tests, the next step was to incorporate AAT into building the product. Or, ensuring we build the right thing from the beginning.
The goal of all of this exercise is to provide clarity at the beginning of development. Developers use requirements or user stories as input for the software. Writing the acceptance criteria as acceptance tests helps clarify any particular points and leads to better questions.
The value of AAT is most visible when the disconnect between the business analyst and developer is visible. The benefit of specification by example is an open dialog between the analyst and developer. Developers have a better understanding of the requirement, and testers can assert a definitive pass or fail. As a result, the Product Owner understands the value of testing. She can see the quicker turn-around and higher quality product demonstrated in delivery.
Now that the Product Owner and client understand the value of testing and see its impact on bugs, the next step is incorporating the quality mindset across the team.
All developers should understand AAT and build towards acceptance tests. All business analysts should use acceptance tests in Gherkin language as acceptance criteria for the user stories to clearly state the requirements and prioritize the tests based on highest return on investment.
Automation of these acceptance tests means you can test faster and deliver faster. You can all add new features without unintended consequences. Continuous integration allows you to run these tests routinely. It creates a repeatable and consistent process.
All of this delivers quality to the client – better quality software, delivered faster, with fewer bugs. Who wouldn’t argue for this?
Agile requirements documentation can mean different things to different people. Before choosing a tool or...
If you are reading this, one of two things has happened to you: The IT...
Often when starting up a new Agile software development project, people ask me the best...