QASymphony / Blog / It’s All about Perception: Acceptance Test Driven Development
It’s All about Perception: Acceptance Test Driven Development
If you want a customer to purchase your product, it’s not just functionality that matters – usability and quality are key factors as well. How end users perceive your product is as important as the actual features that are delivered. Empowering customer perception to drive product performance is the thinking behind Acceptance Test Driven Development (ATDD). Similar to Test Driven Development (TDD), ATDD is a very agile approach to testing, as you define the test in advance, and then write code to comply with the test. This eliminates much of the plodding, requirement-driven process of the old Waterfall method.
The big difference between ATDD and TDD is that while TDD tests against the user story, ATDD tests against pre-specified acceptance criteria. This criteria is driven by customer demand. Here’s what that difference means:
TDD focuses on the user’s interaction with the system: “what happened when they clicked ‘X’”
ATDD is about the user’s acceptance of the system and how they want it to work: “Yes, customers will use the system if it does ‘X’”
Even if the testing at this stage is being performed by an internal tester and not the end user, to develop acceptance criteria you can still plan against what the customer would want to derive value from the system. Then develop a test to meet this criteria and write code just to the point it can pass the test. Team members who are close to the customer can help develop these criteria, such as Account or Support Managers. A focus group could even be used to define criteria at the outset of the project.
But it’s important to remember that criteria must not be subjective. For an ATDD test to be effective, criteria should be explicitly defined such as, “if the system did ‘x,’ then the customer would use the product.” While this may seem challenging to so closely define the application behavior in the early stages, the end result will put you much further down the road to final production. Building the product with the end user’s needs in mind up front will likely have a higher customer adoption rate than applications built through other development methods.