You’re Not Agile Unless You’re Using Behavior-Driven Development

You don’t need to be an engineer to understand the benefit of using behavior-driven development (BDD), but you might just need a Ph.D. in techno-babble to make sense of the definitions you’ll find online.

Even the trusted Wikipedia community has struggled to define BDD. Wikipedia suggests it “combines the general techniques and principles of TDD (test-driven development) with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.”

If someone were to explain behavior-driven development to you this way at a cocktail party, you’d probably quickly slip away to find more delicious appetizers.

Sadly, in part because of the difficulty the industry has had in explaining BDD, its adoption is lagging. So, before I try to convince you that every software development project should implement BDD, let me first attempt to simplify the definition:

Behavior-driven development is a product testing methodology based on what real (human) users might actually do. Philosophically and practically, it is an extension of agile product development.

Agile and the user experience

Agile has been a hot development trend since it came to pass in the early 2000s, and today it’s pretty well entrenched as the standard among the most respected and progressive software companies.

Agile represents two big changes in product development from the traditional waterfall approach. From a process point of view, Agile uses short release cycles, or sprints, instead of the long, very linear release schedules in waterfall development. The advantage in sprints is that a development team can work on a finite group of prioritized features in a short time frame (usually a week or two), complete that work, and then move onto the next sprint. With each sprint, teams can adjust priorities and iterate based on what they learned, such as feedback from user testing, difficulty with implementing specific features, or changes to the competitive landscape.

With waterfall development, a “product specification” is defined and fixed at the start, and there is much less flexibility to adjust midstream without repercussions to the schedule and budget.

The second and most important shift from agile is in how product teams define the products they are creating. In waterfall development, engineering teams often write product specifications based on technology and features in very detailed, technical terms, and these documents serve as the bible for a development project. The problem is that these documents are not universally understood by business stakeholders. And at the end of a project, engineering teams might deliver an interpretation of a product that wasn’t what product marketing wanted.

With agile, instead of lengthy specs about technology and features, teams align on writing lightweight product requirements in the form of user stories based on experiences for real humans. In practice, every sprint’s subtasks are associated with specific user stories.

The user story format is consistent and put in terms that everyone understands:

As a [type of user], I want to [do something] to [achieve some goal/benefit].

The common language of user stories leaves little room for interpretation—from marketing and sales, to company executives, to engineering and design teams. Once everyone is aligned on the expected user experience, it’s then up to the engineers to define the technology they’ll use to deliver that experience.

Behavior-driven development is pure agile

Just as agile development was a big change to product development, behavior-driven development represents a similar shift in how product teams test and validate that a product is performing the way it’s expected to. Again, the user experience is at the center of it.

BDD is pure agile in that test cases, like user stories, are written in a common language that can be understood by all development team members and business stakeholders. Each test case, in fact, maps back to an agile user story and may include several real-world user scenarios—different behaviors that might lead to a product reacting in different ways.

Here’s the basic structure of what a BDD test case might look like for an account sign-up process, including one of what could be several scenarios that make up the test case:

User story:

As someone interested in using the Acme app, I want to sign up in the app so that I can enjoy my membership.

Scenario 1:

Given that I am on the app's "Create new account" screen

*Then* I should see a "Sign up using Facebook" button

*And* I should see a "Sign up using Twitter" button

*And* I should see a "Sign up with email" form field

*When* I click "Sign Up with Facebook" button

*Then* I should see a new screen that asks permission to use my Facebook account data to create my new Acme app account

*And* I should see a button that says "OK"

*When* I click the OK button, my new account should be created

*Then* I should be taken to the Acme app's logged-in home screen

You can see how the user story itself extends nicely into the test case — and how the user experience provides the framework for the BDD test. It’s a stark contrast to what you find in standard unit tests. The limitation of unit testing is that it’s code written to test code, which means it’s understood only by engineers.

Now, don’t get me wrong. I’m not suggesting abandoning unit testing. Unit testing helps surface problems with the code and the code architecture long before it rolls up into an actual feature in an app. But ultimately, the success or failure of an app has little to do with how many unit tests it passes. It has everything to do with how it performs when it’s in the hands of your (human) users.

Why the human matters more than you think

Hopefully the idea of mapping your testing to real-world user behavior makes obvious sense at this point. But there’s another big reason to use behavior-driven development: It could save you development time. Developers can be borderline obsessive over clean and beautiful code, and at times, it’s easy to slip into the habit of writing unnecessary unit tests on code to test factors that simply don’t exist in the real world.

For example, consider if you are designing an app that allows you to measure the dimensions of a room using a phone’s built-in GPS. Using BDD, you would design tests for different scenarios, including the successful calculation of dimensions (e.g., “When I move in x direction 12 feet, And in y direction 10 feet, Then the app should tell me the area of the room is 120 square feet”). And BDD tests would also include corner cases, such as what should happen when a user starts a measurement then drops the phone or hits the start button by mistake in the middle of measuring.

Unit tests, on the other hand, could be written into the code to test how the software makes calculations of many different values and permutations, including negative values, like -10 inches. But in this real-life situation, the movement of the user (and phone) would never generate a negative number.

Behavior-driven development emphasizes real-world scenarios with real humans — and nothing extraneous — so it’s a better use of testing resources.

Think you’re agile? Then stop contradicting yourself

Product development has changed dramatically since I first started in the tech industry in the early 1990s. The single most important development has been the rise of the customer.

For decades, an organization’s traditional customer-facing roles like support, sales, and marketing have passed user feedback onto product development teams. But in many cases, engineering-driven organizations continued to build road maps a step removed from the customer, based more on features and technology and less on user experience. Agile development changed this, putting the user first and foremost for development teams and aligning entire organizations and their systems around the customer experience. Except for how they test and ensure quality.

BDD has been around now for nearly a decade — many trace its origins back to this seminal blog post by Dan North — but it hasn’t been embraced by businesses and product teams with the same level of enthusiasm as agile development.

It’s time to change that. The religion of agile should carry all the way through your organization — from sales, marketing, and support through product development, product delivery, and especially testing and QA. That means using BDD.

If you say you’re agile but you aren’t using BDD for app testing, you’re contradicting yourself.

[Editor’s note: This article was originally published on TechBeacon.]