Aligning BDD with Continuous Delivery

Behavior-driven development (BDD) is a tried-and-true way to build shared understanding of features and stories among team members from different disciplines. It’s also a way to combine the insights from different viewpoints to get a more rounded view of what to build. Let’s explore some ways that BDD fits into and enables continuous delivery (CD).

Continuous delivery (CD) is all about delivering small changes to production frequently and without strain or stress for the team. We want to go from idea to money-making (or money-saving) usage as frequently and easily as possible, for we learn the most when the software is used by real customers.

There are certain steps that are technically necessary to code and deploy a system before it can be used. This gives us a baseline for a system delivery pipeline. 

Of course, things are not as simple as that looks. We need to plan what we’re going to build so that we create something that the customer will pay for. We find ways to build a shared understanding across the team of the capabilities to build. This helps us carve features into thin end-to-end slices, get feedback quickly, and use that feedback wisely to build our confidence to deploy frequently. 

What’s the start of a deployment pipeline?

When a programmer writes a line of code, several things have to happen to turn it into machine code for a computer to run, to connect it with other code and systems to operate together, and to deploy it to the computer where it is executed. Other steps also verify the operation of that code and detect where it does undesirable things. These steps can be triggered manually, but that puts a big burden on people to do the same steps repeatedly in the same way. Computers are good at doing things repeatedly and consistently. It makes much more sense to automate as much of this as possible, and to let people do the work that people are good at.

This series of steps is called a deployment pipeline. Normally, we say that each new commit to the code repository triggers a new run of the deployment pipeline. 

At the same time, we often refer to the infinite “DevOps” loop, with testing all along the way, as envisioned by Dan Ashby.

Our description of a deployment pipeline sounds straight and one-way. Yet a straight-arrow graph is rare. It is more accurate to think about continuous delivery as a cycling loop rather than a linear process. Building software isn’t something you do one time and then you’re done. It’s a process you continue as long as there is need for that software, continually steering it to be more effective at meeting shifting needs.

If you look closely at the typical deployment pipeline pictured above, it only covers the Build, Release, and Deploy activities of the DevOps Loop. The least automatable and most error-prone activities occur before that, in the Plan and Code activities.

How BDD can help shorten feedback loops

We’re fans of holding Three Amigos meetings to talk about the stories the team will start on next. Typically, the “amigos” include a product person, such as the product owner; a programmer; and a tester. One or two additional amigos may be needed, depending on the work to be done, such as a UX designer, a database expert, an operability expert, or even an accountant or other subject matter expert.

These conversations should focus on the purpose of each proposed new change, and the value it brings the user. Techniques like impact mapping and example mapping help the amigos discuss concrete examples of how new capabilities should behave. Examples flesh out the business rules and also help us make sure we mean the same things when we describe those business rules. Often, subtle differences pop up that would otherwise be unnoticed until after the software was built. For example, if there is a reference to a time window of a month, is that to the minute or the day? If to the end of a day, in what time zone? Sometimes “month” is used as a synonym for “30 days,” especially when February is involved. 

This is also the time to talk about how the team should test the changes, and how to instrument the code so we can watch and learn from it after it’s released. 

The examples we use in our Three Amigos conversation make great test cases for automated API testing and UI testing. Think about how much confidence you’ll gain if these examples work as expected. Are there other examples that would give you more confidence? Or perhaps there are other ways to test in addition to these examples. 

In our experience, these meetings help slice user stories into an appropriately small size. Whenever we start coming up with numerous rules or examples for one story, or numerous nodes on our impact map, we know we need to break things down more. Identifying the first thin, end-to-end “learning release” is the foundation for delivering one small change at a time. This shortens the time to getting feedback and reduces risk. 

It’s important for everyone involved in building a new change to share the same vision of the value the change provides and how the software should behave. Doing so makes it more likely that the team members “get it right” on the first go and not waste time with re-work. At least, they get it as right as can be predicted before putting it in front of a user. 

Using examples helps people explore the usage of the system before it’s built. They often uncover some “wrongness” while considering examples of usage. And by clarifying with examples, the team members may find it easier to agree on what “right” means. This is an effective way to shorten cycle time, which is important for successful CD. 

As the team starts to work on a change, they can turn the examples into self-documenting scenarios. They may also automate some or all of those scenarios as tests. These tests guide the programmer and provide the basis of API and UI level tests in the build pipeline. Even tests that are not automated can be a useful guide to testers in the future. 

After automated tests pass, other testing activities are complete, and the product person accepts the change, there is a side benefit: automated regression tests that can remain in the continuous integration (CI) within our deployment pipeline. These become a fast change detector to help us move faster as we implement more small changes. We don’t have to worry as much about unintended side effects if we have tests that alert us to them.

How does CD impact BDD?

The terms “continuous delivery” and “DevOps” were coined a few years after “BDD” became a thing. The principles of CD, as written by Jez Humble and David Farley for their Continuous Delivery book, include “build quality in,” “work in small batches,” and “everyone is responsible.” BDD embraces these same ideas.

If a team’s goal is to frequently deploy small changes to production, it needs to engage everyone. Think about testing first. How do we verify that this change works the way we intend? We need to make the behavior of each small batch clear to everyone who helps to build and deliver it. That sets the right mindset for adopting BDD. 

Doing CD means that we not only get fast feedback from our automated tests in our CI, we also get user feedback in the form of production usage data. That’s a huge help for our discovery process. We can put our first learning release in front of users, using techniques such as release feature toggles and canary launches to restrict access to a small number. We can instrument production code to log all events so we can trace each user’s journey through the application. That makes it easy to find out right away how many people are using a new feature or if they can’t figure out how to use it. 

CD enables the continuous DevOps loop we saw above, with all the learning from production flowing back to the discovery process to refine, delete, or add more small changes. It could be that the users try scenarios that we hadn’t considered in our Three Amigos planning. It could be that some scenarios don’t do what the users want. We can modify our suite of automated scenarios to guide development to better suit the needs of users, while ensuring that we haven’t broken the code for scenarios we want to keep.

BDD for operations

We talk about the customer a lot in Agile teams, but there are “customers” that are easy to overlook. What about people who do technical maintenance on the system environment? For example, is it easy for them to upgrade the storage subsystem? Or to restore a database after a failure? If you’re doing truly integrated DevOps, with the same people building the system also taking care of these sorts of upkeep, they’ll likely think of making them easy for themselves. If that’s delegated to someone else, it’s easy to forget those stakeholders. Treat those people as first-class customers and write scenarios for the things they worry about.

Don’t forget the customer service department, either. When a user calls with a problem, what tools do the tech support people need to determine what happened and how to correct it? Give the customer service personnel the tools they need to provide stellar service. This should be part of the system. 

Monitor what happens in the customer service department the same way you monitor customer usage. This is a rich source of ideas for further development. It’s likely that the tech support staff know more about your users’ needs than anyone else in the company. They listen to the people who are so confused or irritated that they take the time to contact your company! 

How can your team take advantage?

If your team is already practicing continuous delivery, but you’re not guiding development with business-facing tests with a practice like BDD, why not try a small experiment? Look at our list of resources to learn more about BDD. As you plan your next round of stories, have a Three Amigos meeting. Talk about the goal, the business rules, and concrete examples to explain the business rules. Write down your questions so you can get answers.

Before you start writing code, write some scenarios based on those rules and examples. Even if you don’t plan to automate them now, you will get the huge benefit of improved understanding across the team. 

If your team practices BDD but has not yet started moving to continuous delivery, you already have a good foundation on which to build. Start talking about what experiments you could try to start implementing CD. 

What is your current build and delivery process? Remember, whether or not you practice CD, you do have a deployment pipeline. It might be all manual steps right now, but it is still the path your changes have to follow to get into production. The simplest first step is often writing scripts for the manual steps. You can and should apply continuous delivery principles, even if you don’t yet have the infrastructure in place to support it. 

Whatever your team’s current situation, start building relationships among the people who design and build new features and the people focused on maintaining and improving the deployment pipeline. Everyone involved in delivering the product and taking care of it in production, everyone taking care of customers or trying to attract new ones, the business people who are collecting the revenue and paying the bills... -- Everyone has something to contribute to solving customer problems with frequent, valuable new changes. The better you align these efforts, the more smoothly the process goes. And the more smoothly these changes flow, the more quickly you can respond to changing circumstances and customer needs.

Resources for further learning

• Discovery: Explore Behavior Using Examples, by Seb Rose and Gáspár Nagy
• Introducing Example Mapping, by Matt Wynne
• Continuous Delivery, by Jez Humble and David Farley
• A Practical Guide to Testing in DevOps, by Katrina Clokie
• Accelerate The Science of Lean Software and DevOps, by Dr. Nicole Forsgren, Jez Humble, Gene KIm
• “The Three Amigos — All For One - One For All,” by George Dinwiddie, in Better Software, November/December 2011, Volume 13, Issue 6, pp. 24-27
• “The Three Amigos Strategy of Developing User Stories,” by George Dinwiddie, AgileConnection

The promise of continuous testing is faster delivery of higher quality software. This white paper summarizes its advantages and disadvantages.

by Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of three books: Agile Testing Condensed: A Brief Introduction, More Agile Testing: Learning Journeys for the Whole Team, Agile Testing: A Practical Guide for Testers and Agile Teams; the LiveLessons Agile Testing Essentials video course, and “The Whole Team Approach to Agile Testing” 3-day training course offered through the Agile Testing Fellowship. Lisa was voted by her peers as the Most Influential Agile Testing Professional Person at Agile Testing Days in 2012. She is co-founder with Janet of Agile Testing Fellowship, Inc. Please visit www.lisacrispin.com, www.agiletestingfellow.com, and www.agiletester.ca for more.

‍

by George Dinwiddie

George Dinwiddie helps organizations develop software more effectively. He brings decades of development experience from electronic hardware and embedded firmware to business information technology. He helps organizations, managers, and teams solve the problems they face by providing consulting, coaching, mentoring and training at the organizational, process, team, interpersonal, and technical levels. Involved in the Agile community since 2000, he has helped organizations ranging from a 6-person startup to a Fortune 100 company and a billion-plus dollar federal program, either directly or in partnership with other companies. He is the author of Software Estimation without Guessing: Effective Planning in an Imperfect World (Pragmatic Bookshelf), Evolutionary Anatomy of Test Automation Code (LeanPub) and co-author of Patterns of Agile Journeys (LeanPub).