Behavior Driven Development (BDD) is picking up steam in the software community. For those who aren’t familiar with BDD, it is an agile approach to software development that embodies the essence of collaboration between business folk, designers, developers and testers for creating test cases based on common user behavior.

It isn’t uncommon to hear people say, “I want to automate my tests using BDD.” One thing to keep in mind is that BDD is not synonymous with test automation. It will not ensure the quality of your software. However, it is an approach that describes a collaborative process that allows various internal stakeholders collectively design acceptance criteria that drive the development of quality software. In this way, it contributes to software quality and checks if the developed code meets the business expectations or not. However, to ensure the quality of your product, you should look to the testing pyramid for guidelines on your testing practices. For example, this is how the testing pyramid looks like for the Hiptest platform:

 

BDD scenarios help our team create software that directly ties back to a user value- not just creating features for the sake of features. Behavior Driven Development will help you to develop the right thing- software that matters and delivers measurable value. Therefore, having this conversation between all theproject stakeholders about how the software should solve users’ needs, is where BDD has the biggest impact.

Start with the End in Mind, i.e., the Benefits of Your Feature

When you have a new feature to develop, you should start by focusing on the benefits this feature will deliver to its users. Start by answering the “WHY,” or the intent. Why should we develop this feature? Why would this feature help my user? These questions are a great way to steer the conversation towards what really matters- the user. In BDD, a feature should have a description that provides the context to a need being met. It is usually written this way:

In order to [get a benefit]

As a [role]

I want [a feature]

At Hiptest, we decided to develop an integration with Slack. The integration was requested by many Hiptest users to get constant updates about their testing projects directly from Slack.

Before starting anything, we stopped to ask ourselves WHY? Why did our users want this feature? How would the feature benefit their lives? By focusing on the user value first, we were able to narrow down our scenarios to the use cases that had the biggest impact on our customers. Our development team quickly identified two use cases that led to two different authentication architectures. The impact of the different architectures on the design was important and needed to be evaluated. Our two options were:

• Anyone from the team should get notified in Slack (using a project’s token for the authentication)
• Only Hiptest users (having an Hiptest account) should be able to get notified in Slack (using a user’s token for the authentication)

As we wanted to make the biggest impact on teams using slack, we chosen the former option that allowed anyone on the team to get notified, because it had the most user value. This solved the real need of notifying all the team members including those without Hiptest accounts.

Having this discussion before starting development saved a lot of time, and we were able to kick off this project by creating our feature definitions.

As you can see from the graphic, our team at Hiptest created the feature description for this use case as:

In order to stay up to date on the progress of my project directly within my messaging app

As a team member

I want Hiptest to notify changes on my messaging app

Now that we have a clear understanding of the benefits of writing feature descriptions with the end focus in mind, let us move on to writing test scenarios.

 

 

Be declarative when writing scenario

With your test scenarios, you’ll be able to describe the different use cases through examples. At this point, focus on the “WHAT” and not the “HOW.” There are two styles for writing your user stories: the imperative and the declarative styles. With the imperative style of writing, test scenarios can be long with low-level steps that describe how to drive or navigate the user interface. Conversely, when using the declarative style of Gherkin syntax, test scenarios describe the WHAT, not the HOW. The declarative style is strongly recommended because it focuses on fulfilling business expectations and driving user value, rather than focusing on how to create a test that does the same.

For example, when testing the simple use case of adding an item to the cart in an online store, the declarative style of writing the test scenario could be:

Given I am logged in

When I add an item to the cart

And I click on the cart

Then I should see the item I added

It doesn’t matter how one did the login (whether using a username, password, touchID, etc.). The only thing that matters from a business perspective is that the user logged in. Details of the login procedure will be pushed into the step definitions when automating the scenario, in the declarative style, however, they are tirelessly included in the imperative style. Therefore, you can really see how the declarative style is precise and to-the-point, whereas the imperative style of writing test scenarios is long-winded with unnecessary information that doesn’t capture the user value.

Here, you can see that for the slack integration, the Hiptest team, created the following declarative test scenario:

Given I have activated Slack in the settings of my Hiptest project Coffee Machine

When I query /hiptest TestRunID from slack

Then I should see the breakdown of tests by statuses for testRunID

It’s also important to ensure that business terminology is used consistently across all your scenarios. This way it becomes a common language shared by all the team members. To establish consistency across all the test scenarios, tools like autocompletion are also helpful. Additionally, it is important to have the right refactoring capabilities to manage the impacts of changes on your test scenarios.

Our last suggestion is to review and refactor your test scenarios continuously. These are good practices to ensure the health of your code.

Key BDD Takeaways

The mantras of getting started with BDD are:

• Focus on the benefits of the feature
• Be declarative when writing test scenarios.

These best practices can get you started on your journey towards developing great software. Once your team is sufficiently proficient at creating user-centric stories for all the proposed features, you can then elevate your software development by automating your BDD test scenarios. After driving the conversation towards BDD, building out test scenarios and then automating them, the final stage of the journey is having a way to share these feature definitions dynamically with a common support for both business and technology stakeholders. This can be achieved through living documentation. As the usage of BDD in your teams increases, so does the value or benefit you receive from it.

By driving the conversation with BDD and focusing on value first, the impact on your organization will be immediately recognized. With this, teams can finally focus their development efforts on what really matters at the end of the day- making users happy.