Many developers treat behavior-driven development (BDD) like test-driven development (TDD). Rather than using it as an opportunity to communicate with product owners, they write the tests in isolation and then write the code necessary to make the tests pass — the same as they would with TDD tests.

If you treat BDD like TDD, then you’re probably missing out on most of the benefits. BDD is designed to improve communication between business and technical teams. If there’s no communication, these tests become a redundant form of TDD with little benefit. But, how should you involve business teams?

Let’s take a look at where business teams fit into the BDD process, and in particular, who should write the BDD scenarios to realize the greatest benefit.

Running a Discovery Meeting

Behavior-driven development begins with a discovery meeting that involves a product owner, test engineer and software developer. The goal of the meeting is to get everyone on the same page through a conversation involving concrete examples of how a feature should behave.

Each person on the team plays a specific role:

• Product owners are responsible for determining the scope of the application, including the translation of user stories into features and the acceptance/rejection of features.
  
  
• Test engineers are responsible for generating scenarios and thinking through the edge cases. They ask questions like, “how could the application break?” and “What user stories were missed in a given set of features?”.
  
  
• Developers are responsible for adding steps to the scenarios and reason through the details. They ask questions like, “How will the application work?” and “What are the potential technical roadblocks behind the scenes?”.

[content_upgrade cu_id="5373"]Download our free Checklist of Tips for Writing Effective BDD Scenarios.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]

The meeting begins with a user story that’s about to be pulled into production. After introducing the user story and acceptance criteria, the team comes up with concrete examples of the user story. They also document any questions or concerns that come up along the way, which could be a reason to delay the story.

The concrete examples form the basis for executable specifications called scenarios. These scenarios are written in a language called Gherkin that’s easy for business teams to understand. Step definitions are added to these scenarios to actually complete the tests.

Who Does the Writing?

Test engineers are typically responsible for writing scenarios while developers are responsible for writing step definitions. However, this doesn’t mean that they should be responsible for writing these things in isolation following a discovery meeting — the best approach is a collaborative one.

Each team member contributes specific expertise:

• Product owners ensure that scenarios remain in-scope and relevant to the business values.
  
  
• Developers ensure that scenarios are described in a way that will deliver the product owners’ desired features.
  
  
• Test engineers uncover things that everyone else misses — the edge cases that can cause major problems.

John Ferguson Smart recommends that acceptance criteria are recorded and automated in a pair-programming session with both a tester and product owner. The tester takes ownership of the scenarios at that stage, but product owners are required to ensure that the scenarios stay true to their original intent.

Similarly, the developer and test engineer might pair-program the development of step definitions to ensure that no edge cases are missed. The developer takes ownership of the scenario at that stage, but the test engineer can help ensure that nothing falls through the cracks that could cause issues.

The test engineer may be responsible for seeing the scenario through the various stages of development and liaising with the product owners and developers, but they shouldn’t be solely responsible for taking notes from the discovery meeting and translating them into step definitions in isolation.

Writing Effective Scenarios

There are several things to keep in mind when writing scenarios and step definitions.

[content_upgrade cu_id="5373"]Don’t forget to download our free Checklist of Tips for Writing Effective BDD Scenarios.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]

The biggest mistake that beginners make is writing imperative rather than declarative scenarios. For example, many teams write imperative scenarios with low-level steps like navigating to pages, filling in fields or pressing buttons. Declarative scenarios describe what the user does rather than how they do it, which covers more high-level business rules.

Another common mistake is adding too many examples to an example table. For example, a test covering search functionality probably doesn’t require multiple examples of a similar search query. Teams should focus on narrowing down examples to those that are easy to understand for stakeholders and represents separate behaviors.

Finally, it’s important to write scenarios with a consistent style and structure. Many stakeholders and non-technical team members rely on feature files as a sort of living documentation. Teams should limit each file to one feature to make them easy to find, use a consistent layout throughout and ensure proper spelling and grammar.

Simplify with HipTest

HipTest provides an easy to use web-based interface for business and technical teams to define scenarios and generate step definitions. Through this interface, anyone can define acceptance criteria, execute automated tests and generate living documentation without knowing how to read code.

Screenshot of the HipTest Scenario Builder

When writing scenarios, stakeholders and test engineers that are collaborating on a project can do so in a way that both parties understand. Test engineers and developers can then automatically generate step definitions from feature files using HipTest Publisher and ensure everything look good.

HipTest cuts down on the time required during these meetings by improving communication while integrating with over 20 different testing frameworks. You can even integrate tests with common continuous integration platforms to bring all of your tests under a single umbrella.

The Bottom Line

Behavior-driven development is all about improving communication between team members. Rather than a single team member taking over the entire scenario-writing process, you may want to consider involving multiple team members at different stages to realize all of the benefits.

HipTest makes it easy to collaborate and improve with a web-based interface and numerous automation tools. Sign up today to get started for free!