Test Drive the Agile Acceptance Test Driven Development (ATDD)

Test Drive the Agile Acceptance Test Driven Development

An offshoot of Test Driven Development, ATDD puts emphasis on the customer by making acceptance test cases the foundation of development. In this methodology, acceptance test cases are created even before coding starts. These test cases then become the reference for development and failing these test cases at any stage implies requirements have not been meant. Thus, this methodology affords instant feedback on whether development is attuned to customer aspirations.

Stages of ATDD

  1. User Story: ATDD typically begins with a user story which encapsulates what the user expects to see at the end of development. Discussions between stakeholders sees the user story being extrapolated into actions or tasks the system needs to perform to satisfactorily meet the user objectives.
  2. Acceptance tests criteria: The output from the above step becomes the input for deriving the acceptance test criteria. Starting from an initial list, these test cases are extended to take into account all scenarios that may come into play in real time and how the system should respond in each scenario.
  3. Test case automation: The next step is to automate the acceptance test cases. The test cases are turned into an executable format that can be loaded to a testing tool. Tools like Fitnesse, Cucumber and Concordion are popularly used for automation in ATDD.
  4. Implementation: Acceptance test criteria becomes the basis for development. Development generally happens in a piecemeal fashion wherein the TDD model may be used to code, test and refactor until a test case is passed. At the end of several small iterations, we have the new functionality up and running.
Related :   7 Core Practices of Agile Test Automation

The above is, of course, the ideal chain of activities but in real time, coding and test case automation may often go hand in hand.

Benefits of Acceptance Test Driven Development:

  1. More focus on customer needs: As the user acceptance test criteria is taken as the basis for development, the customer objectives remain in focus throughout development. Developers can visualise the end result holistically which leads to better coding and unit testing. ATDD forces the developer to think from a customer perspective and focus on end user needs at all stages of development.
  2. Better collaboration between stakeholders: Collaboration starts right from the point where the user story is written down and continues till the developed code meets the acceptance criteria. Product Owners, Business Analysts, testers and developers work together throughout development. The user story and acceptance criteria give all members of the team a clear picture of what needs to be achieved and ensure better adherence to requirements.
  3. Faster resolution of issues: Unlike regular development cycles, in ATDD acceptance testing is not an isolated activity performed prior to roll out. It is an integral part of development and is performed multiple times to check whether the new code conforms to expectations. This helps in early identification and resolution of issues.
  4. Easier to manage: ATDD development occurs in several small iterations which means the team needed for such projects is small. Smaller teams are easy to build, are often experienced and have the right skills required for the job. Managing resources and infrastructure is also easy compared to large development teams, not to mention the fact that smaller teams often tend to have better rapport and be more collaborative than large teams.
Related :   Challenges of Implementing Continuous Integration (CI) at Scale

Agile testing from Gallop

At Gallop, we understand your need to deliver good quality software in a time-challenged environment. And that is why we bring to our clients the advantage of colocated agile test services. Contact us to know more about our agile test practices and how we can help you fine tune your agile projects.

The opinions expressed in this blog are author's and don't necessarily represent Gallop's positions, strategies or opinions.