When creating software, agile product groups are always trying to capture the most information, in the simplest way. Each team member’s goal is to accurately express their needs, so that they can get ahead of the curve—for analysis, for development, for testing, for documentation. The faster and more completely a team can express what they are trying to build and test, the easier it is to realize that vision.

This process is supported by a “daily drill,” which defines the challenges that we encounter every day in software development:

How can we design better software, faster?

How can we design better tests for our software, faster?

How do we explain our needs–needs we can easily express in everyday English–in a way that Development and other teams can understand?

And, to further support this here at Motivis Learning, we’ve adopted Behavior-Driven Development (BDD) as our approach to product testing.

What is Behavior-Driven Development?

Behavior-Driven Development (BDD) is a term for test methodology that essentially uses the application’s expected behavior, not the expected implementation, as the test. It seems absurdly easy, but asking the question How do I want this application to ‘behave’? will result in the scaffold for your test. You don’t need to worry about the actual implementation. Simple, right?

What makes BDD so accessible? To define tests, BDD uses Cucumber, which is a “plain language” language. The syntax is comprised of simple sentences started with words like “Given,” “And,” “But,” and “Then.” There’s no real mystery, because it’s written in everyday English, and it’s very consumable, regardless of your background. As long as you can read, you can use BDD.

Here’s an example of a simple test definition for an Edit Profile feature. As you can see, it’s easy for anyone to read and understand.

In addition to how easy it is to follow, you may have noticed that there are no real implementation details in the example. You’re telling the developer that you want to be able to edit a photo on the “LRM Personal Information” page, but you’re not being particularly detailed in explaining how that should happen from a technical standpoint. And that’s okay, because…

BDD Facilitates Flexible Implementation

One of the core ideas behind BDD is to insulate the test case from changes in implementation. As long as the desired behavior is the same, you don’t really have to be concerned with how the developer implements the code. In other words, if a specified int gets changed to a float in the middle of a sprint, it doesn’t bother the test case one bit as long as the shopping cart feature still displays the correct price. Even if the Development team has completely scrapped the original implementation and re-worked the code, the QA team doesn’t need to make any updates to the test case as long as the resulting behavior still applies.

Sounds Great. How Do We Start?

The good news is that there are easy ways to add BDD to your testing efforts without completely revamping your QA process.

We started small by adding BDD test cases to cover a single, previously-released sprint. Because our existing Automation footprint was small at the time, this single sprint served as the perfect bite-sized chunk to get us started. At the end of the process, we had a nice, cozy suite of feature files that were perfect for regressing our sprint.

People immediately recognized the value—you could run the BDD suite and instantly regress the stories contained within.

Obviously, this was a big time-saver, and it freed up the QA team from the mundane task of re-testing old stories prior to a release. Good times all around!

And the Starting Part…?

Here’s the step-by-step explanation of how the process works at Motivis Learning:

1. Test Planning with Acceptance Criteria

When Product stories are written, they include acceptance criteria from the Product team. This acceptance criteria is the basis for developing the BDD. The acceptance criteria is what defines the “behavior” that the Product Owner is expecting when the feature is complete.

For example:

These few lines define the picture of success for the developer doing the work. It also forms the basis of what the QA team wants to test.

2. Turning Acceptance Criteria into BDD

Once the acceptance criteria is defined, the QA team then takes that criteria and turns it into a test case, or more often than not, several test cases. Here’s the initial test case. It’s likely that your team will be writing more than just this one case; there may be a corresponding negative test case, or a version for a different user persona.

3. Adding the Test Case to the Test Repository

A repository tool isn’t necessary, but we use TestRail to store the cases that we develop because we can hook it to the original JIRA story, as well as to the automation framework using an embedded step that hooks into a simple JSON call: “Given that I set the testcase id to 92”, which tells the automation exactly which test case is being referenced. That can then be used for reporting purposes–you can tell immediately which test cases have passed or failed.

4. Create a Feature file

BDD is stored in “Feature” files. Once there’s a test case in place, we then create a new JIRA ticket for the Automation team. They then pick up the test case and turn it into a Feature file.

5. Turn the Feature File into a Step Definition

Once the Feature file is available, Test Engineers can then turn it into Step Definitions. As you can see, the Step Definition is easily updated if, for example, the web page was renamed from “LRMPersonalInformation” to something else:

And the best part is, the Test Engineer doesn’t have to go back and update the test case, because the test case is not tightly coupled to that page name. It’s abstracted to a “Personal Information Page for a Student”:

This means a drastic drop in the maintenance of your test cases. You no longer have to create elaborate Excel spreadsheets accounting for every single click on a screen, and no longer must you hunt down those “clicks” and update them after every Development pass. As you get comfortable with the way BDD works, you might even find that you…gasp…enjoy writing test cases!

There’s Resistance…Does it Have to Be All or Nothing?

It can be difficult to get beleaguered testers to adopt yet another “system” for generating test cases. People might find themselves unwilling to adapt to the “vagueness” of BDD. It doesn’t feel as satisfyingly detailed as a traditional step-by-step test case. It feels too “easy”, or that there may be gaps in coverage because not every single click is explicitly laid out.

The best way to start is probably to try running against a single sprint. The syntax, while easy, does take a little practice and a certain amount of agreement within the QA team to find the correct grain for some stories, because people will invariably try to document every click and implementation detail at first. This can be a hard habit to break, but with some practice, you’ll get better at abstracting away from the precise implementation and really giving more thought to the behavior.

At The End of the Day

In short, BDD is a great tool without a lot of overhead or a requirement for extensive training. At the end of the day, it can help your agile team meet the challenges of the “daily drill” of software development by providing:

Clear Needs: Thanks to “plain language”, everyone on the team will have a clear understanding of what is being produced and tested.

Better Product: A behavior-centric ethos takes shape, and Product people are driven to consider the outcomes by answering the question, What should it do?

Better Testing: The QA team will be freed from the drudgery of maintaining high-touch, tightly-coupled test cases and have more time for more coverage, or for higher-value testing.

In the end, this effort translates to tighter product, development that accurately reflects requirements, and faster or broader test coverage. With outcomes like that, you can’t help but have happy customers!

Author: Sam Clarke

Sam Clarke is the Director of Marketing at Motivis Learning. He's a proud native of Salem, Mass., often waxes poetic about the economy, and holds a BA in Classics from Union College.

1 thought on “Getting Started with Behavior-Driven Development”

I added a unit test that failed if developers didn’t check in a specification file for the story they were working on (which the build process knew because there was another test that failed if the branch name didn’t end with a story number).