Acceptance Test-Driven Development

Acceptance Test-Driven Development (ATDD) steers software development based on real usage scenarios.

In an ATDD-based approach, software specification and implementation is directed by means of concrete examples. Describing real use cases as tests forces the designer to define the software specifications in detail that is beyond the capabilities of traditional requirement specification documents. It also reveals potentially conflicting requirements in the specifications. In the traditional approach, the role of acceptance testing is less important: acceptance tests are carried out afterwards, if at all.

The ATDD approach is based on the idea of performing automated acceptance tests, even before the programming stage, allowing the team to immediately test the targeted functions. The tests may be defined by users, customers or functional specifications specialists while programmers or testers carry out their automation. While thought should be given to test definitions when planning an iteration or project, it is more natural to automate feature-specific tests immediately before programming each feature.

Using the terminology of testing guru Brian Marick, these tests are business-facing i.e. they are expressed in business terms, contrary to the technology-facing tests of TDD, which is a programming technique. In practice, the tests demonstrate essential workflows or business logic rules. For example: ”When you add a product worth EUR 100 to the shopping cart, the total amount increases from EUR 250 to EUR 350” or “The discount for purchases worth more than EUR 100 is 5% and for purchases worth more than EUR 300, 10%.”

Automated acceptance tests tell the development team whether the implementation of the feature complies with the specification. While they do not eliminate the need for manual testing, particularly as concerns the user interface, automated tests enable testers to focus on tasks where people outperform machines (see also “Test automation” in the article Quality Assurance and Testing). Failure to automate acceptance tests means that the testers will waste their time on regression testing, i.e. testing existing functionality just in case. Likewise, the developer will have to wait for feedback as manual tests can take up to several days.

Business-Driven Software Design

Setting up automated acceptance tests in advance speeds up software development due to rapid feedback cycles. A traditional problem in software development is that the implemented functions fail to meet the customer’s needs. Defining acceptance tests in advance in cooperation with the customer helps the development team ensure that the desired functions will be implemented as required by the customer.

ATDD takes the business-driven approach to the extreme. The work begins with the concrete functions on which the customer should focus its valuable development resources. The technical solutions and details are chosen to directly serve the needs of the business.

The quality and appropriateness of acceptance tests is of primary importance in ATDD. A problem sometimes occurring in Agile software development projects is that the customer is forced to assume too much responsibility for the specification and other decisions. An example can be found in the article The Agile Physician [PDF] (IEEE Software, June 2007). At Reaktor, the functional specifications specialists discuss the design with the customer and users, but the responsibility for designing the user interface or work flows remains with the specialists. The customers’ key task in this process is to help our specialists understand their business and the tangible goals the software may help them achieve.

Lasse Koskela, Methodology Consultant

Lasse is a methodology specialist at Reaktor. He spends most of his time training and coaching software development organizations around Agile Methods and engineering practices in Finland and Europe.