Acceptance Test Driven Development ATDD

Software that meets user needs

The key to any successful software project is to create software that fulfills an actual need. Only a thorough understanding of this need ensures that the software's functionality serves a real-life purpose that helps businesses and users achieve their goals. In other words, everyone collaborating on the software development should have a collective understanding of why the functionality is necessary and how the software should work.

In agile development methods, software is developed iteratively. This iterative approach makes it possible to update or redo functionality if it does not match customer needs. Sometimes this is truly necessary – a natural and inevitable consequence of the project's ongoing learning process. However, many things could be done "right" the first time around with a small dose of pre-emptive planning. A proper planning method prevents unnecessary rework.

Acceptance Test Driven Development (ATDD) is a method that uses dialog between the customer and the development team to define and clarify software requirements or user stories. The customer and the team create a set of acceptance tests that describe when functionality can be considered complete. Guided by this shared vision, the implementation is more likely to meet business and user needs, resulting in less rework and a better bottom line.

Specification workshops – what are we doing and why?

Acceptance Test Driven Development begins with a specification workshop, which involves the customer (the product owner, business representatives, and technical experts) and the entire implementation team (designers, developers, and testers.) The workshop comprises two phases, the first of which seeks to answer questions like "Why?", "When?" and "Who?" Why is this feature important? In what situation does the user need it? Which users need it? The discussion inspired by these questions is used to achieve a collective overall understanding of the functionality's purpose.

In the second phase, the functionality is specified in more detail, focusing on what the software should do and how it should work. The acceptance tests, created as a collaborative effort by all the participants, serve as the basis of the discussion. The purpose of the acceptance tests is to provide a specific definition of how the functionality should work.

Any issues unearthed? during the discussion are resolved in the workshop. Additional workshops are arranged until all issues have been resolved. The workshops are worth repeating because the resolution of one issue often opens up a variety of new issues and a list of unanswered questions. This means, of course, that workshops must be arranged at an early enough stage of the process. For example, in the "Scrum" development process, the specification workshop is a natural part of Backlog Grooming.

At the end of the specification workshop, the participants should have a collective understanding of what each particular requirement means. The acceptance tests document this collective understanding of each desired functionality.

Acceptance tests drive development

Once there is a consensus on the requirements, the team needs to tackle two tasks concurrently: the implementation of the desired functionality and the automation of the acceptance tests created earlier in the workshops. The automated acceptance tests drive development, and they provide information on a feature's current status. The tests are run each time a change is made. This ensures that any discrepancies between the implementation and the documentation (i.e., the acceptance tests) are spotted without delay. Since the functionality and automated tests are developed concurrently, the testability of the system is guaranteed.

To improve the quality of the developed software , exploratory testing is carried out during the implementation phase. If new information is discovered during development or exploratory testing, new acceptance tests are added accordingly. Acceptance tests help the development team to verify that the implementation is complete and meets the agreed specifications.

Once the functionality has been implemented and acceptance tested, it is demonstrated to the project's interest groups. The purpose of the demo is to deem the functionality ready for release or to identify necessary improvements.

Regression testing prevents design debt

As the project progresses, the number of automated tests grows. Only with this high level of test automation, an adequate level of regression testing can be reached. The automated acceptance tests verify the successful implementation of existing functionality while the team concentrates on developing new features. Regression tests also help the team to refactor their code, thus helping them avoid design debt. Because tests are run continuously, issues can be discovered quickly – which makes fixing them both fast and cost-efficient.

Over the course of the project, Acceptance Test Driven Development produces a functional description of the software. The description serves as documentation for the functionality, and it remains up-to-date as the acceptance tests are always run against the latest version of the software.

The right people at the right time?

The cornerstone of ATDD is the development workshop. Successful workshops lay the foundation for the entire process, but in order for a workshop to be successful, the right people need to participate – people who can provide detailed answers to specific questions and who are able to make decisions concerning the prioritization and scope of various features. The participants should also represent a variety of roles. This ensures that the workshop has a sufficient range of distinct viewpoints, which makes it easier to add detail to functionalities and limit their scope. As a bare minimum, the workshop should include the customer, designer, developer, and tester. Usually, the entire development team is present, which also makes the specification workshop an excellent forum for information sharing.

In addition to the right people, success requires concrete information. An acceptance test needs to have enough details. The discovery of undefined or conflicting functionality is often only possible through the use of concrete examples. If your acceptance tests are too abstract, you sacrifice most of the potential benefits of Acceptance Test Driven Development.

Juha Rantanen, QA Expert

Juha has several years of experience using ATDD and has helped numerous customers implement the method with success. He is a popular speaker at international conferences.