Why BDD practice fails, and the right way to write BDD steps

How to implement proper BDD steps to deliver quality features

Why should you be trying behaviour driven development? Unfortunately, user stories and requirements are not enough to get the full picture of the feature. The concept at the core of BDD is creating documentation we can rely on.

There are a bunch of definitions out there of what BDD actually is. In my opinion, one of the most solid definitions is this one:

BDD is the process designed to help management and help to deliver more quality projects rapidly by improving communication between business and engineers.

BDD incorporates a lot of different techniques and activities performed by stakeholders, business analysts, developers, and QA.

We can divide BDD processes into the following stages:

• Discovery workshop: a kick-off meeting to discuss requirements that are mainly user stories to understand them through collaboration with proper acceptance criteria and examples. If necessary, we can break down user stories into separate, smaller tasks to discuss them. If a story is too big and the details are unclear, we should contact business for more details. We should always discuss stories before adding them to the sprint list when we follow the Scrum methodology. The most important factors are discussion, communication, and team members should work together rather than work alone. Generally, the 3 Amigos (BA, Developer and QA) are always at these meetings. Those 3 need to carefully look at the product from different sides and provide various insights. That will make the user stories clear and from there, we are able to plan our following sprint more precisely. It is during the discovery stage where we start testing to understand the feature and business.

Since the main goal of BDD is to quickly deliver good quality new features, this is the stage where we can get immediate feedback, define the strong and weak points, and change requirements. We can save time while developing features to deliver the product faster to the business.

• Formulation: after discussing our requirements, they have to be formulated. We formulate our system requirements in BDD by moving them to a Cucumber format (readable by business). This means that we define them in the Gherkin language. This process of writing scenarios means that all teams (QA, BA and developer) will work together. They can’t be written by the QA or BA and then assigned to the developer to start implementation. It won’t work, since BDD is about communication. We achieve better results when we discuss and communicate. By the end of the formulation stage we should have both the readable by business and executable scenarios of system behavior.
• Automation: after we have defined our scenarios, our goal is to transform our scenarios into automation tests to verify the system’s behavior. At this stage, our automation tests can use any programming language and framework. After this, our scenarios don’t just describe the system’s behavior but they’ll also work as auto tests. Finally, we get a satisfied team and satisfied clients.

However, be careful when implementing BDD as there are factors that can disrupt development and cause failure.

• BDD is not Functional testing: do not add all validations because the behavior list will be so long that nobody will read it. BDD can help when executing regression tests or verifying main scenarios. However, incorporating validation for all errors into BDD scenarios isn’t worth it because we shouldn’t be utilizing BDD for exhaustive testing. We don’t have infinite resources or infinite money, so we need to have a suitable level of confidence to deliver our features.
• BDD is not about testing: for us more important communication and achieve a common understanding of the requirements by all participants. Many people are thinking in the wrong direction, that BDD is a set of keywords and one of the automation frameworks. BDD is about software behavior. BDD is not something that QAs must do by themselves, it’s not about automation and testing tools. Both the business and developers should be involved as well. However, it’s a great framework to highlight stakeholders and to give them confidence through evidence. The mindset of people involved in Quality Assurance is important for successful deliveries, which is why testing starts at the discovery stage.
• Prevent bugs: the main idea of BDD is not to find bugs when implementation finished, but to prevent future bugs, which is why discussion and communication between all parties involved is of the utmost importance. This is why we have to write as many as possible scenarios to prevent potential bugs, but they have to be written wisely to avoid an exhaustive list of scenarios.
• Having leaked scenarios: it’s important to revert our system to its initial state, because if we don’t, sometimes our scenarios can generate failures.
• All scenarios e2e: when there is an attempt to make all scenarios e2e, that is test for the whole system. This is the wrong approach because the scenarios will be overloaded with steps and test executions. Our tests will be too long, the feedback will arrive back late, and our tests won’t make much sense.

How to write proper BDD scenarios and steps:

Gherkin syntax:

• Given: use this keyword to outline the preconditions that are necessary for the scenario to be executed by the user.

Example: Given I’m on the website as a guest

• When: use this keyword to describe the action to be performed

Example: When I enter a valid username and a valid e-mail address

• Then: use this keyword to describe the outcome of the actions

Example: Then login is successful

• And/But: use these to connect any of the previous keywords if you want to duplicate a previous step
  Example: the following examples are identical and both are valid

Given I'm on website as a guest 
Given I open Login overlay
When  I login with a closed account
Then  login is unsuccessful
Then 'Incorrect username or password' tooltip should appear
-----------------------------------------
Given I'm on website as a guest
And   I open Login overlay                                                                                          When  I login with a closed account                                               Then  login is unsuccessful
And   'Incorrect username or password' tooltip should appear

• Background: if we have steps that can be used for multiple scenarios we can use this section
• Examples: this is used to outline the values within a scenario. Examples are in a table format.

Best Practices of writing Gherkin steps:

• Create isolated, reusable steps and actually use them repeatedly

Instead of creating a step to buy 2 items, create a step to buy any number of items. The basic mistake people involved in the BDD process make is creating Gherkin steps that are too detailed and not reusable.

Tests should mostly focus on what we need to achieve, and not the details of how we are going to achieve it.

• Create behavior-driven steps, not procedural

Write steps as if they were written by a user. Avoid steps referring to specific elements or selectors. This part of the process should be developed by the 3 Amigos. The generated steps should be clearly understood by stakeholders and not specific to a certain part of the code or an element on the interface.

• Each scenario should describe a single behavior

When creating steps for a scenario, try to limit the scope of it to 1 specific behavior for that feature. This is the main rule of BDD.

• Use Backgrounds and Scenario Outlines as much as possible

You can use these keywords to make your feature files briefer. However, use Background wisely, because if you put too many steps in there, your scenarios can become hard to understand.

• Use a limited number of And and But for your scenario

If you use more than 3 And or But operators, there is a big chance that you’re not following the previous steps. You probably attempted to create steps that are not reusable or that have too big a connection with the existing UI

• Try not to use punctuation such as periods and commas within step phrases

They can cause unrecognized errors when you try to investigate why step definitions failed.

• Unify steps and avoid using different syntax for the same steps

Defining steps differently will cause issues and duplication of steps. Below, you will find a single step defined in 3 different ways.

Examples:

I should see ‘Logout’ option
I see log out option
I see logout option

• Get rid of steps that can’t be automated and can’t be checked on the website

Examples: Given I’m not connected to company network

• Given, When, and Then steps must appear in order

A Given may not follow a When or Then, and a When may not follow a Then. The reason why is that a single When, Then pair only tests one specific behavior. Otherwise, if we add multiple pairs we might be testing 2/3/4 behaviors, which according to our best practices, we should not be doing.

That’s why it’s better to split those into 2/3/4 separate scenarios.

• Make sure you incorporate basic steps into your scenarios

Before adding steps related to a specific story, we have to add a step that opens the website and adds our other precondition steps.

Given I'm on website as a guest

• Keep the definitions of different steps that share logic on different pages, especially when you use completely different elements on them.

Example: we should use different steps when building a login form on a Login overlay than when building a Forgot password overlay.

Instead of Fill login form, use Fill login form on Login overlay or Fill login form on Forgot Password overlay

Conclusion

BDD is a great framework to deliver quality features and increase the level of communication between the business and the engineering team. However, most still misunderstand the basic aims and objectives of BDD. BDD is not about automation and testing. BDD shouldn’t cover all functional tests and end-to-end tests. BDD is about collaboration between different stakeholders to make a clear product, and investing time and effort into the most relevant developments.