The Phases of ATDD
The practice of doing analysis via the discussion of acceptance criteria and writing the results in the form of acceptance tests is known as both Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD). The intentions of both are the same, the biggest difference is in the formatting of the test specifications. If teams are having difficulty breaking features into small stories, the Given-When-Then format of BDD may be the preferred starting point.
ATDD using BDD is one of the first things all companies should adopt, whether they have already transitioned to Agile, are desiring or starting to transition, or are even staying with a traditional or Waterfall approach. It is such a critical discipline that we’ve built our team-level approach for people wanting to use Scrum.
Starting with BDD/ATDD is both easier and safer than starting with traditional Test-Driven Development (TDD). TDD is often difficult and risky to do with legacy code. Not only does BDD/ATDD allow software development organizations to better meet stakeholder expectations, it also results in better overall code quality. This is because considering tests prior to writing any code is the first mantra of design patterns. It results in better design while helping avoid extra code. Other benefits include better tester-coder alignment, coordination, and collaboration.
BDD/ATDD can be adopted in stages. These are discovery, where we discover what the requirements are, specification where we create scenarios for what we’ve discovered automation where we automate the scenarios.
The first part of discovery virtually no extra work and the rest of discovery takes very little and all return great value. As one goes deeper into full implementation, even more value is achieved. The important thing is to realize that you start where it is best for you.
Discovery is the beginning phase of ATDD. It is where we initially discover what the requirements are. As we go deeper into ATDD additional discovery will be made. There is no implication that this discovery phase is absolute or cannot be revisited. Rather it is just the start of the process.
Level 0: Ask the Question “How will I know I’ve done that?” and consider tests prior to writing code
At a minimum, developers should both ask the question “How will I know I’ve done that?” while also considering how they will test their code prior to writing it. This doesn’t take any extra work. It’s merely changing the order in which steps you are going to do take place. Even if they don’t document anything, this mere consideration of behavior is a kind of design. This is actually the first mantra of design patterns and greatly increases testability. Doing this as a practice takes virtually no additional effort. Instead, one should think about it as a rearrangement of the order in which the workflow is done occurs. Instead of:
- Consider what is needed
- Consider how to validate what is needed <—
We are putting step 4 up above step 2:
- Consider what is needed
- Consider how to validate what is needed <—
We call this “Level 0” because it doesn’t require any extra work.
Level 1: Use test specifications as an analysis tool and to validate the requirements
The next level is for developers to validate their understanding with the BA/PO/Customer. This small documentation is useful for the obvious reasons that it will help when anyone has to come back to maintain the code. But the real value is the quick feedback provided to the developers on their understanding of the requirements.
Level 2: Have Business Analysts, Product Owners, customers, developers, and testers write acceptance criteria together
One of the biggest advantages of BDD/ATDD is that it changes the nature of the conversation between whoever is representing the customer, the developers, and the testers. It is a great way to uncover assumptions that will cause waste. And assumptions are killers to clarity. Many times we make assumptions without realizing they are assumptions (something we don’t know and we don’t know we don’t know it). In these cases, we don’t know the right question to ask to discover the mistaken understanding. In Level 2, getting the different roles to talk to each other and create acceptance tests, these hidden assumptions tend to get discovered.
Specification is taking what we’ve discovered and converting them into scenarios. There are several ways to do this. We tend to prefer Given / When / Then because it enables breaking big stories into small stories in a straightforward manner.
Level 3: Use Given / When / Then as a format
BDD is often thought of as being defined by GWT. But the two are not synonymous. While tool support is available for GWT, it is not required to get massive benefit. GWT means:
- Given a <situation>
- When an <event>
- Then I want this <behavior> to occur
Note that GWT specifically ignores how to implement the behavior.
While the ubiquitous “As a < type of user >, I want < some goal > so that < some reason >” is a good place to start, it is often difficult to create small stories with this. GWT can be used to slice up any feature, no matter how complicated, because the “Given” and “When” can be made more and more specialized.
Although a lot of teams think they need to improve code quality with TDD, the reality is that starting with acceptance criteria can reduce bugs by up to 95%. It also is the first mantra of design patterns (design to behavior).
BDD’s (behavior-based development) GWT enables people to get down to small stories (every time) as well as setting up for automated testing. The “As a …” can still be used as a description of the first story/feature to provide the “why” of what is being asked for. But after that first case (or soon thereafter), it’s better to go with GWT.
Level 4: Put acceptance criteria into a test-tool harness
In this level, acceptance tests are implemented in a test tool or harness as soon as they are captured. This is not difficult. Once the acceptance tests are defined (which is the more involved part), writing the acceptance tests is easy, especially if you are using a test tool or harness. While you’ve got them, you might as well capture them!
Automation is the final stage and highly recommended. The largest investment in time is in discovery and specification. While automating the tests is not necessary, if you’ve gotten this far this final investment is well worth it.
Level 5: Automate the tests
Some test harnesses make this automatic. However, even if you have to do some work here, it will pay itself back quickly by reducing regression testing. Think of all the places where tests currently don’t exist and manual regression testing slows you down. Don’t keep adding to that pile.
BDD/ATDD is not tool-driven. It is a thought process and an essential part of Agile Product Management. The fact that it can be automated is just an additional advantage.
How Long It Takes to Adopt ATDD
There is no set time frame for adopting ATDD. Much of it depends upon how much energy the team is intending to take. You should do level 0 (asking the question “how will I know I’ve done that?”) all the time. It doesn’t slow things down and is almost always useful. Level 1 doesn’t take a lot of time either. However, as you go up the higher levels each story takes more time to write tests for. We advise doing as many of these as you can but recognize that at first things more time – so you may not be able to do all of them this new way.
The increasing return for step-wise investments. Consider what level is appropriate for your group. Consider the ROI for each level’s benefit of BDD/ATDD. While it may be difficult to start with a full adoption of BDD/ATDD, virtually every development group should start at Level 2 or higher. It’s really not that hard.