What Is Acceptance Test-Driven Development?
Ken Pugh, a consultant at Net Objectives, sat down with Ade Shokoya from Agile TV at the 2012 Agile Development Conference East to answer the question—What is Acceptance Test-Driven Development?—and does so, so masterfully, that it’s difficult to find a better explanation anywhere. By comparing software development to building a car, the benefits of acceptance test-driven development become immediately apparent.
Acceptance test-driven development (ATDD) differs from test-driven development (TDD) in one major way. ATDD offers a far more collaborative approach, an approach that involves business analysts and even the customers themselves. It is arguably one of the ultimate agile tools.
TDD by itself, without the added acceptance, sprung from agile beliefs, and its iterative approach qualifies it as an agile practice. However, the weight and impact of acceptance, even as technical as it is when used in this field, increases the level of agility to new heights, through rampant collaboration from the beginning of a project.
Both development practices embrace the “test first, code later” mentality, but by inviting business analysts into the equation, the roles of both testers and developers become altered—for the benefit of the final product and the client’s satisfaction with the result.
In ATDD, the role of the tester evolves to one that guides developers, so that both of their jobs become easier. The idea that a tester’s only need on a project is to “break” the work of a developer—and not to provide the framework for a developer to follow so that all work can be completed faster and with greater precision—becomes almost archaic.
That word acceptance is what eliminates negativity everywhere, even in the most basic, standard terminology. Pugh makes note of this when he remarks:
Requirements and tests are tied together. You can’t have one without the other. If a tester comes up with a test after developers have finished implementation—that is a new requirement, not a defect in the code.
In the above interview, Pugh points out that with acceptance tests provided up front, developers are able to test their code against them from the start, thus eliminating the potential for vast amounts of rework later in the project. Pugh mentions that in one recent case he observed, a group reduced the number of defects in a single release from four hundred to zero.
The time that would have been necessary to fix and eliminate that number of bugs was now able to be spent implementing features and—for the ultimate in client satisfaction—delivering the finished product, the better product, faster.
Is a tester's job only to break code, or should testers provide a framework for developers to follow? Add your two cents in the comments section below.
