Introduction

In the dynamic world of software testing, ensuring the final product aligns with user expectations is crucial. For Quality Assurance (QA) professionals, Behavior-Driven Development (BDD) has emerged as a powerful methodology due to its collaborative and user-focused approach. BDD bridges the gap between technical and non-technical stakeholders, fostering a shared understanding of desired software behavior through clear, concise, and executable specifications. This collaborative approach significantly enhances the QA process by ensuring all team members are aligned on the requirements and expected outcomes.

In this blog, we will delve into the essentials of BDD, explore the Gherkin language used for writing BDD tests, and share best practices for creating effective BDD scenarios. By the end, you’ll have a comprehensive understanding of how BDD can enhance your QA process, ensuring high-quality software that meets user needs and expectations.

Table of Contents

• What is BDD?
• What is Gherkin Language?
• Best Practices for Writing BDD Tests
  • Write test scenarios as early as possible
  • Features and Scenarios
  • Use Background
  • Try to re-use step definitions
  • Use a Data Table
  • Use Scenario outline
  • Use of Tags
  • Map your scenario with the requirement
  • Avoid Conjunctive Steps
  • Write in a declarative way, not Imperative
  • Rules for writing Scenarios in Cucumber
• Main Rules for BDD UI Scenarios
  • Gherkin’s Golden Rule
  • The cardinal rule of BDD
• Concluding Thoughts

What is Behavior-Driven Development (BDD)?

Behavior-Driven Development (BDD) is a software development technique that encourages collaboration among developers, testers, and business stakeholders. It focuses on the behavior of the system from the user’s perspective. BDD helps in ensuring the software meets the users’ needs and expectations by defining scenarios that describe the desired behavior. This approach is crucial for successful BDD development, as it aligns technical and non-technical team members around common goals.

What is Gherkin Language?

Gherkin is a structured language that is used to write BDD tests. It uses a specific syntax that is easy to read and understand for both technical and non-technical team members. Gherkin scenarios are written in a Given-When-Then format to describe the expected behavior of the system in a clear and concise manner. Mastering Gherkin is essential for effective BDD development, as it ensures clarity and precision in defining user stories.

In BDD, “Given-When-And-Then-But” is the proposed approach for writing test cases. Listed below is an example of BDD.

In the above example, there are many keywords, and every keyword has its own meaning and purpose.

Let’s explain each keyword with respect to the above example.

• Feature Keyword: The feature file starts with the keyword Feature. Under feature, you can mention the feature name which is to be tested, as seen below,
  • Feature: User login into the site with valid data and Invalid data
• Scenario Keyword: There can be more than one scenario under one feature file, and each scenario starts with the keyword Scenario, followed by the scenario name. In the below example, we can see there are two scenarios.
  • Scenario: Login as a new sign-up user with valid data
  • Scenario: Login as a new sign-up user with invalid data
• Given Keyword: Given keyword is normally used when we have to give some pre-condition in our test case as seen in the example below,
  • Given User is on the home page of the site Or Given User is on the  Log-in page of the site
• When Keyword: When the keyword is used to perform some action, as depicted in the example below,
  • When the User enters an email Or When the User clicks on the “Log in” button
• And Keyword: There is no annotation for AND keyword. It is used to connect two statements and provides the logical AND condition between any two statements. AND can be used in combination with GIVEN, WHEN and THEN statements and used for positive assertion.
  • And the user clicks on the login button
• Then Keyword: Then Keyword is used for the final outcome or for validation.
  • Then User should be logged-in successfully
  • Then Error message should be displayed
• But Keyword: But the keyword is used to represent negative assertions in addition to the previous statement.
  • But Log-in button is not present
  • But Re-login option should be available
• Background Keyword: If there is any repetitive step that is going to be used in every test case. We just add the repetitive step under Keyword Background. Step keep under Background would be run before every test case.
  • Background: Given User navigates to the Website

Best Practices for Writing BDD Tests 📝

When writing BDD tests, it’s essential to follow certain best practices to ensure the effectiveness and efficiency of the tests. 

Here are some key best practices to keep in mind:

1. Write test scenarios as early as possible

It’s a good practice if we are ready to write test scenarios before creating test code. Developing scenarios early helps you define software behavior and understand possible problems in a better way. Once a scenario is ready and reviewed by team members who agree with it, we can start implementing the functionality. This will save time and effort and take away uncertainty later, during the development, or when your team will run acceptance tests.

2. Features and Scenarios

A feature is a product functionality, whereas a scenario is the specification of behavior.

• Feature file:
  • Feature file should be specific to the page, meaning if you have to cover the login scenario we should create a “login.feature”
  • A single feature file can contain multiple scenarios
  • Avoid mixing feature files
  • Every feature should be ready to be executed alone
• Scenario:
  • To describe the scenarios, Gherkin keywords are used: Given, When, Then, But and And During writing the scenario we have to make sure we should use keywords in an appropriate way.

See below an example of a poorly written scenario.

A better way to write the same above scenario with fewer lines is as follows. It is best to avoid details that don’t contribute much.

3. Use Background

It is always the best practice to put steps that are repeated in every scenario into the Background. The background step is run before every scenario.

Ensure that you don’t put too many steps in there, as your scenarios may become harder to understand. Given below is an example.

4. Try to re-use step definitions

It’s best practice to reuse those step definitions that we are using frequently in various scenarios e.g “Given: User navigates to the Website” this can be one common step that we need in every scenario. So we can reuse this step.

Reusing the steps improves the maintainability if just in case there’s any change come we need to update in a single step.

We have to make sure language/words should be consistent if we want to re-use the step.

In the below example step is the same the but word isn’t consistent Click and clicks both are different words. So we have to take care of case sensitive to re-use the step.

Given (“Click on ‘Sign In link’ on the Home Page”)

Given (“click on ‘Sign In link’ on the Home Page”)

• Step Definitions dos and don’ts
  • Don’t call a step definition method from another method.
  • Never hard code any test data in step definition.
  • Learn how regular expression is used to match a Gherkin step and a Step Definition method.
  • Chain the assertions to enable code readability.

5. Use a Data Table

It’s recommended to use Data Table to store the data. We can give data as parameters within the step but once we have a large set of data then it’s not feasible to relinquish all data as parameters. It’s better to use a data table once we have a large set of data.

The data table is used to inject data at the step level. In the below code we have provided data for step “I entered valid credential”.

6. Use Scenario outline

Scenario outline injects the info at the scenario level rather than the step level. Scenario outline followed by the keyword.

7. Use of Tags

Using tags could be the best practice once we want to run a bunch of test cases. There will be the case that we don’t want to execute all test cases in a single run or we would like to execute a group of the test cases. So the best practice is to configure the test case by putting Tags on it. They are marked with @ followed by some text.

For example, a group of smoke test cases and sanity tests is created. You can put a tag over the scenario like @SmokeTest, @SanityTest, @RegressionTest, etc.

8. Map your scenario with the requirement

It’s a best practice if we will provide the requirement number (#Jira story id) after the scenario in the feature file. If any scenario fails, then we can track which requirement is fail from the execution report (See below test case execution screenshot).

For example, in lines #7, and #15 of the code below, the required number is specified for better tracking.

9. Avoid Conjunctive Steps

During writing the feature best practice is we’ve got to avoid conjunctive steps. When you find a Cucumber step that contains two actions in conjunction with an “and”, we should always have to break it into two steps. It is into two steps. Keeping one action per step makes steps more modular and increases reusability. This is not a general rule though. There are also reasons for conjunctive steps. However, most of the time it is best to avoid them.

10. Write in a declarative way, not Imperative

Scenarios should be written in a way the user would describe them. Beware of scenarios that only describe clicking links and entering data in form fields, or of steps that contain code. This is not a feature description. Declarative features are realistic, compendious, and contain highly maintainable steps.

• Example of Declarative Scenario:

• Example of Imperative Scenario:

11. Rules for writing Scenarios in Cucumber

Test scenarios should be written in a way that is easy to understand and clears for every team member.

Below are some common recommendations.

• Proper use of correct grammar and spelling
• Step definitions should not end with periods, commas, and other punctuation marks.
• Use correct punctuation
• Avoid jargon

Main Rules for BDD UI Scenarios ⤵️

In the world of Behavior-Driven Development (BDD), there are two important rules for UI scenarios:

👉 Rule 1: Gherkin’s Golden Rule

Gherkin’s Golden Rule is simple: Treat other readers as you would want to be treated. Write feature files in such a way that they are easily understandable by everyone involved. Good Gherkin enhances team collaboration by clarifying the behaviors being developed. When Gherkin is difficult for others to comprehend, it hinders the development of good behaviors.

To illustrate this rule, let’s examine scenarios from the perspective of a team developing a website for a shoe store:

Ultra-Declarative Scenario:

This scenario lacks specificity and clarity. It doesn’t provide enough details about the desired behavior, making it difficult to understand what actions are being performed and how to verify them. It’s not automatable and lacks accountability.

Ultra-Imperative Scenario:

This scenario provides excessive detail, overwhelming the reader with a lengthy list of low-level interactions. While each step is automatable, collaboration becomes challenging due to the verbosity and lack of focus.

Optimized Scenario:

This scenario follows the given-when-then structure, providing clear steps that describe the setup, interaction, and verification of the behavior. It uses concrete examples like “red pumps” to enhance understanding. The scenario is concise, unambiguous, and facilitates collaboration.

In summary, adhering to Gherkin’s Golden Rule ensures that scenarios are readable, automatable, and scalable, fostering effective collaboration within the development team.

👉 Rule 2: The cardinal rule of BDD

The cardinal rule of BDD is a one-to-one rule: One scenario should cover exactly one single, independent behavior. Focusing on one behavior at a time has several benefits:

• Collaboration: More focus and less confusion
• Automation: Each test failure points to a unique problem
• Efficiency: Less complex work makes for faster cycle times
• Traceability: 1 behavior → 1 example → 1 scenario → 1 test → 1 result
• Accountability: Teams cannot hide or avoid behaviors

 It’s easy to spot a scenario that covers more than one behavior. Consider this scenario:

This scenario covers two separate behaviors: searching for shoes, and searching for images of shoes. Each when-then pair denotes a unique behavior. Whenever a scenario has more than one when-then the pair, it inherently covers more than one behavior. Thankfully, splitting scenarios is easy:

You can capture the stopping point for the first scenario as a new given step for the second scenario. In this way, the second scenario focuses only on its unique behavior. You can also use automation to try to optimize this given step by taking shortcuts such as a direct link.

For further information on Behavior-Driven Development (BDD), please visit the official website.

Concluding Thoughts:

In conclusion, mastering Behavior-Driven Development (BDD) involves understanding its core concepts, including the Gherkin language and the main rules for crafting UI scenarios. BDD emphasizes collaboration, automation, efficiency, traceability, and accountability in software development. The Gherkin language serves as a bridge between technical and non-technical team members, enabling clear communication of requirements through human-readable scenarios. Adhering to the cardinal rule of BDD ensures that each scenario addresses a single, independent behavior, fostering clarity, focus, and effectiveness in the development process. By following these principles, teams can streamline their workflows, improve collaboration, and deliver high-quality software that meets user needs and expectations.

Witness how our meticulous approach and cutting-edge solutions elevated quality and performance to new heights. Begin your journey into the world of software testing excellence. To know more refer to Tools & Technologies & QA Services.

If you would like to learn more about the awesome services we provide, be sure to reach out.

Happy Testing 🙂