This is a guest blog post from Kevin Dunne of QASymphony, makers of qTest for Scenario for Jira.

Everyone in a product company has felt the pain and anxiety of waiting for testing to be completed so that valuable features can make it into the hands of customers.  In accepting the status quo, we either rush features out the door with low quality, or we push out deadlines and disappoint customers to make sure we deliver software we can stand behind.

Many years ago, some smart people devised a better way to develop software quickly and with high quality using a test-first methodology in place of a traditional requirements-driven approach.  In this approach, the software development lifecycle is effectively put on its head.

Traditional approach

Screen Shot 2016-02-04 at 10.28.25 AM

Test-first approach

Screen Shot 2016-02-04 at 10.28.11 AM

What’s changed in this new test-first approach? First, testing has been automated and moved in front of coding. This means that code is developed to make the test pass. Secondly, these tests act as the requirements, removing one layer of documentation in the process, and limiting the risk of tests and code being built to a different understanding – pretty cool! Finally, we allow the developer only to write code until the test passes, then refactor that code to find a more elegant solution while still passing the code.

This test-first approach became increasingly popular and was coined as test driven development (TDD), but businesses quickly realized it didn’t give them the visibility and coverage they needed for the most important business cases in their systems. So, a variant of TDD was born called behavior driven development (BDD), focusing on the behavior of the system rather than its technical specifications. Now, organizations could push features quickly with quality AND confidence that they met end user expectations.

Though organizations are eager to see a quick payback using BDD, there are upfront investments that need to be made before benefits can be realized. Generally, these investments fall into three buckets: process, technology, and people.

The behavior driven development process

Adopting the “three amigos” model


In BDD, specifications are created via the close collaboration of testers, business analysts, and developers. In a traditional (waterfall) organization, these teams may rarely collaborate and might not even be co-located, so there are many changes that may need to occur. Scrum teams may have the collaboration and co-location part solved, but rarely will have the 1 tester:1 analyst:1 developer ratio in place, so changes will still need to be made.

Writing features/scenarios

Transitioning to correctly structured and defined scenarios is a must to achieve behavior driven development – otherwise, it’s really just still TDD. One obvious shift is to the structure format described via BDD depicted below:

Sample Feature w/ Scenario

Feature: serve coffee

Coffee should not be served until paid for
Coffee should not be served until the button has been pressed
If there is no coffee left then money should be refunded


Scenario: buy last coffee

Given there is 1 coffee left in the machine
And I have deposited 1$
When I press the coffee button
Then I should be served a coffee


Equally as important as making the structural shift in features/scenarios is getting more thorough collaboration up front, as to not be surprised by costly last minute changes as you prepare to release.


Choosing a framework

In my experience through launching qTest Scenario, there are dozens of behavior driven development frameworks to pick from, each of which has a horde of fans proclaiming it to be the only BDD framework they’d ever use. I have found that many of the frameworks accomplish the same thing, so there are 2 key aspects to look out for:

  1. How does the framework interact with your desired process? Some allow the feature to be merged to a user story (like BDDfy), which may eliminate duplicate documentation
  2. What language is it built upon? Frameworks built on Ruby and Python are typically easier for manual testers to pick up, but more seasoned developers may prefer to develop tests in the language their application is written in (Java, .NET, etc.)


To get started with behavior driven development, developers may need to build “testability” into the application, by way of mocks, API’s, etc. that can forgo the UI and interact with automated tests in a more repeatable fashion. Developers often see this as technical debt, which they may prioritize below customer facing features, but these enhancements are critical to BDD success.


Behavior driven development requires daily cross-functional collaboration to succeed. We know that many developers, testers, and analysts are not used to this and will oppose this change. All members of the engineering organization must be aligned to work together for any BDD initiative to succeed.


Many organization are loaded with manual testing talent, but lean on automated testing personnel. While behavior driven development can be achieved through manual testing, it is most effective when testing is automated. Organizations should invest in developing manual testers into automated testers, involving developers in automation discussions, and transitioning strictly manual testers to business focused approaches like exploratory testing to maintain their value add.


We hope this serves as a brief guide to get you thinking about a possible transition to behavior driven development. Any other tips on making a BDD transition? Share them below!

Did you find this post useful? Share it on your social network of choice and help your fellow software makers get hip to BDD!

Making the shift to behavior driven development