The practice of doing analysis via the discussion of acceptance criteria and writing the results in the form of an acceptance test is known as either 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 are transitioning to Agile, are just about to or are even staying with a Waterfall approach. It is so critical that we’ve built our team level approach when people want to use Scrum around it which we call Scrum/APM (Agile Product Management).
Starting with BDD/ATDD is both easier and safer than starting with Test-Driven Development (TDD). TDD is often difficult and risky to do with legacy code. In any event, BDD/ATDD has a, perhaps surprising, result on overall code quality. This is because considering tests prior to writing any code is the first mantra of design patterns. It results in both better design while helping avoid extra code. Other benefits include keeping testers and coders in synch and increased collaboration.
BDD/ATDD can be adopted in stages.The first takes virtually no extra work and the next two take very little and both return great value. Even more value is returned as one goes deeper into a full implementation.The important thing is to realize that you an start where it is best for you.
At a minimum, developers should consider how they will test their code prior to writing it. 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 being done occurs. Instead of:
We are putting step 4 up above step 2:
We call this “Level 0” because it doesn’t require any extra work.
The next level is to for developers to validate their understanding with the BA/PO/Customer. This small documentation is useful for the obvious reasons 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 of 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 talk to each other and create acceptance tests, these hidden assumptions tend to get discovered.
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:
Note that GWT specifically ignore 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.
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!
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.
Be clear that 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.
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 at least Level 2. It’s really not that hard.
BDD/ATDD is so important that we’ve integrated levels 0-3 into the course, Scrum with Agile: Requirements:Achieving Sustainable Agility.
We are happy to talk with you in more detail to let you know how.