There are quite a few agile development methodologies that lean companies use today. Acceptance Test Driven Development (ATDD) is a popular one that I’ve had the most experience in, so I’d like to give a quick primer to what ATDD is, some of its benefits and drawbacks, and a simple test example.

What is ATDD?

ATDD is an agile development methodology that emphasizes close discussion and agreement among developers, product managers, and QA testers about the end product’s specifications, before any coding takes place.

Typically when a product manager presents requirements for a product the developers ask clarifying questions to make sure they understand what is being requested. However it’s quite common that misunderstandings still happen –  depending on how the developers interpreted the requirements and clarifications, the actual end product could turn out very differently from what the PM originally had in mind.

ATDD minimizes much of these misunderstandings because everyone involved is discussing what exactly is needed in the end product in order to satisfy the original requirements. What’s discussed and agreed-upon becomes the acceptance tests, which the QA testers run against the finished code to verify that every point specified has been met.

Benefits of ATDD

ATDD increases communication within the team and decreases misunderstandings because the team discusses and agrees upon the exact behavior of the end product. It’s especially useful at preventing unknown or unintended misunderstandings.

Drawbacks of ATDD

ATDD is less flexible because it becomes harder to change requirements after acceptance tests are written and coding has begun. ATDD is also process heavy and may result in multiple tests with only minor differences.

Given-When-Then Formula

Acceptance tests are commonly written in the Given-When-Then formula:

Given (setup)

When (trigger)

Then (verification)

So a big-idea example would be:

Given I have a bag of gummy worms

When I open the bag

Then I should see red/blue, yellow/red, and green/orange gummy worms

Workplace Example

At the ecommerce company where I work, the PM works closely with the software engineers and QA engineers to go over the requirements and answer any questions. The QA engineers then write the acceptance test feature files (given-when-then), which are discussed and approved by the PM and developers.

Usually when I review these feature files, I pay close attention that each scenario covers the requirements I originally specified. I also check to make sure that there are no missing scenarios. Since these feature files are written in the given-when-then format, there are a lot of repeated phrases and setups. It may seem tedious but it’s essential to carefully go over each scenario – it’s on the PM if something wasn’t implemented according to plan, since the PM signed off on it.

Once the feature files are signed off, the developers proceed to write code and the QA engineers run the tests using these feature files. If everything matches up, then the test passes and the process is repeated for the next product feature. If the test doesn’t pass, then the team goes back to determine if the issue is a defect. If it is a valid defect, the team fixes it so the test can pass.

It’s important to note that acceptance tests are automated, and QA engineers work with an automation framework such as Selenium WebDriver to execute these tests.

Have thoughts that you’d like to contribute around acceptance test driven development? Chat with other product leaders around the world in our PMHQ Community!