The idea of acceptance tests -- a set of tests that must pass before an application can be considered finished -- is certainly not new. Indeed, the value of testing an application before delivering it is relatively well established. But the way most organizations do it comes too late in the process and is not well-integrated with the actual development process. A new approach called acceptance-test-driven development (ATDD) can change that.
Traditionally, testers prepare test plans and execute tests manually at the end of the software development phase. Acceptance testing is done relatively independently of development activities. In some organizations, QA departments also use automated testing tools such as HP's Quick Test Pro, but, again, this activity is generally siloed away from the rest of the development activity.
[ 10 years on: Did agile development deliver? | Learn more about why you should adopt continuous integration development. | Keep up with the latest Java news and insights with InfoWorld's JavaWorld Enterprise Java newsletter. ]
Testing an application after it has been developed has several significant drawbacks. Most important, having feedback about problems raised at this late stage of development makes it very difficult to correct bugs of any size. This results in costly rework, wasted developer time, and delayed deliveries.
ATDD takes a different approach. Essentially, ATDD involves collaboratively defining and automating the acceptance tests for upcoming work before it even begins -- a simple inversion that turns out to be a real game-changer. Rather than validating what has been developed at the end of the development process, ATDD actively pilots the project from the start. Rather than being an activity reserved to the QA team, ATDD is a collaborative exercise that involves product owners, business analysts, testers, and developers. And rather than just testing the finished product, ATDD helps to ensure that all project members understand precisely what needs to be done, even before the programming starts.
In addition, acceptance tests are no longer cantoned to the end of the project and performed as an isolated activity. Instead, ATDD tests are automated and fully integrated throughout the development process. As a result, issues are raised faster and can be fixed more quickly and less expensively, the workload on QA at the end of the project is greatly reduced, and the team can respond to changes faster and more effectively.
ATDD in practice
Consider how ATDD typically works in the context of an agile development project. As a rule, a software project aims at delivering users with a number of high-level "features" (sometimes called functionalities or capabilities). A feature is a general value proposition relating to something the application can do for the user, expressed in terms you might put on a product flyer or press release; for example, a feature of an online real estate lease-management application might be "Manage property repairs."
Features are generally too big to implement all at once, so they are broken into smaller, more manageable chunks. In agile circles, these chunks are often expressed in the form of user stories -- a short sentence capturing what the user wants from a particular piece of functionality. For example, user stories for the "Manage property repairs" feature might include "Issue work order" and "Approve invoice."
