Acceptance Test-Driven Development (ATDD) is a part of the agile methodology where automated tests are written from the user’s perspective. Unlike test-driven development – where acceptance tests are created from the perspective of the developer – ATDD advocates the automation of tests from the various perspectives of the user.
Understanding Acceptance Test-Driven Development
Here, acceptance tests are generated through collaboration between what are known as the “three amigos”, including:
- The customer – what problem is the organization trying to solve?
- The developer – how might the problem be solved?
- The tester – who considers and verifies potential solutions.
Ultimately, the collaboration seen in Acceptance Test-Driven Development allows software development teams to meet acceptance criteria. When new features are created, one or more acceptance-level tests are written before the code itself is written. Following this process, development teams can test code based on certain conditions, triggers, or requirements supported by each of the three amigos.
Only after acceptance is attained should the code be refined to meet quality standards. Another way to think about ATDD is that the developer writes just enough code to meet the required functionality and pass the acceptance test. This means that the ATDD methodology gives instant feedback on whether the various stages of product development are meeting customer needs.
An example of a typical ATDD process
Following is a typical ATDD process explained in four distinct stages:
- Define user stories. What does the user expect to see once the product has been developed? A user story is an end goal as opposed to a product feature and must be expressed from the perspective of the user. Each should be an informal and general description of no more than a few sentences.
- Establish acceptance test criteria. User stories then drive the creation of acceptance test criteria. Each test should incorporate criteria that encompass a broad range of potential scenarios and detail how the system might respond to each.
- Automate the tests. Tests are turned into an executable format by using tools such as FitNesse, Concordion, and Cucumber.
- Implement the criteria as the basis of product development. Teams may choose to use the developer-centric TDD model to refine code until a test is passed. In passing these tests, it’s important to reiterate that no more effort be expended than necessary.
Benefits of ATDD
- Increased efficiency. Studies have shown that teams using the ATDD process saw rework decrease from 60% to 20%. In other words, productivity doubled because the time available for developing new features climbed from 40% to 80%.
- Enhanced collaboration, which begins with the definition of user stories and ends with code meeting acceptance criteria. With product owners, consumers, analysts, testers, and developers involved in every step of the process, there is a higher probability that performance and other standards are achieved.
- Faster problem resolution. During ATDD, acceptance testing is not an isolated activity performed before rollout. Instead, the code is checked and rechecked with input from key stakeholders to ensure that it meets expectations. This encourages the identification and resolution of issues as they occur.
- Acceptance Test-Driven Development is a methodology advocating communication between customers, developers, and testers.
- Acceptance Test-Driven Development stipulates that user stories are determined before any code is written. After user stories have been defined, code should be created according to certain user story criteria.
- Acceptance Test-Driven Development increases efficiency and collaboration in development teams. The iterative nature of the ATDD process also facilitates faster problem resolution.
Main Free Guides: