Building 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.

Where We Started

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:

1. Have enough of an understanding of the requirements to lay out scenarios and sample data.
2. Prioritize the list for testing. Start with the critical features, then work through the highs, mediums, and lows. This initiative is similar to building the product – deliver the highest value items early.
3. Get all of the relevant participants (testers, analysts, and developers) together to agree on testing approach, criteria for prioritization, and method for writing the acceptance tests.

Where We Are

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.

Where We Want To Be

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?