What is BDD Testing? A Complete Guide

BDD testing is the software testing practice of describing test steps in simple language so that both technical and non-technical stakeholders can have a shared understanding of the code.

The goal of BDD is to improve collaboration between the technical side and the business side of the organization.

BDD vs. BDD Testing

BDD (Behavior-driven development) is the methodology for software development where testers use a shared business language to describe software scenarios.

A common BDD language is Gherkin. Here's a description of the Login scenario written in Gherkin:

Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid credentials
    And clicks the login button
    Then the user should be redirected to the dashboard
    And see a welcome message

BDD testing is the process of automating and executing these BDD scenarios.

What is the Gherkin language?

The Gherkin language is a unique business-readable language used to describe system behaviors and scenarios. It is structured by three primary statements: Given, When, and Then, with each statement describing a specific aspect of the system.

• The Given statement sets up the initial context for the behavior and defines the starting point of the system.
• The When statement describes the trigger that brings about a change or behavior in the system.
• The Then statement defines the expected outcome that should be observed after the event mentioned in the When statement.

After articulating the system behavior in Gherkin, BDD testers turn it into a test script that can be understood by the computer.

Rules In Writing Gherkin Statements

• Besides Given, When, and Then statements, testers can also use other keywords such as Feature, Rule, Example, And, But, Background, Scenario Outline, Examples to describe the behavior. 

• You should use these keywords at the start of a line.

• Comments are permitted at the start of a new line and begin with optional spaces, followed by a hash sign (#) and text. 

• Indentation can be achieved using spaces or tabs, with a recommended indentation level of two spaces.

Why Do We Need BDD?

BDD is based on the idea that the tres amigos (i.e., three friends) in software development don’t always share the same perspectives. A common ground between them must be established to facilitate smooth communication.

The tres amigos include:

• Product Owner: representing the business side, they simply want to solve a problem they have.
• Developer: representing the development side, they want to build a solution to solve the problem of the Product Owner.
• Tester: representing the QA side, they want to know if the solution can actually solve the problem, and what can possibly go wrong with the solution.

The traditional approach to testing does not connect the perspectives of the tres amigos:

• Stakeholders come to the product owner to transfer their requirements

• The product owner then explains those requirements to developers and testers.

• Developers then translate the requirements into code, while the testers translate them into test cases.

It was a lengthy process, and loss in translation can occur, which inevitably leads to misunderstandings.

Instead, with BDD, the tres amigos come together and have a discussion, then turn the insights into a documentation using a shared language to create a common understanding of the issue at hand. Testers can then use a BDD testing framework to create test cases.

Advantages of BDD Testing

With BDD testing, you can:

• Have a common language for engineers and stakeholders to communicate about user needs and software solutions.
• Craft user stories and scenarios to define acceptance criteria for specific software features.
• Promote collaboration among users, quality team, product team, and engineers to achieve consensus on the project's goals.
• Reduce uncertainties.
• Enable faster product delivery by the rapid creation of mutually agreed upon automated tests.
• Reduce errors in software implementation by converting business requirements into a clear format for all executed tests.
• Minimize the learning curve and jargon.

Limitations of BDD Testing

However, BDD testing is not without limitations:

• Potentially leads to lengthy stakeholder meetings and the inclusion of all key stakeholders in the BDD process.
• Demands well-prepared software requirements for the Gherkin scripts to accurately express the business needs, which may conflict with the fast-paced nature of Agile teams working from concise specifications.
• Less efficient for small development teams.

Steps To Do BDD Testing

Day-to-day BDD activity involves a three-step process:

1. Discovery
2. Formulation
3. Automation.

These steps help your team confidently make changes to the system. The code reflects the documentation, which reflects everyone's understanding of the problem.

1. Discovery Stage

During the Discovery stage, stakeholders participate in structured conversations called discovery workshops (also known as brainstorming sessions) where they discuss and reach a mutual agreement on the desired goals.

They start by stating the user story or requirement in a concise format, such as:

“As a [role], I want [goal] so that [benefit].”

After that, they brainstorm examples of how the user story should behave in different scenarios. These examples focus on concrete situations and help to define the expected behavior.

The team then writes each example on sticky notes or a digital tool, arranging them in a structured format. A common format includes:

• Columns for the example
• A brief description
• Rules or constraints
• Any open questions or areas of uncertainty.

This approach is known as “Example Mapping". Created by the founder of Cucumber, one of the most popular BDD testing frameworks, Example Mapping’s goal is to create a shared understanding of user stories or requirements by breaking them down into smaller, concrete examples for the three amigos to follow.

2. Formulation Stage

The team converts discussions into feature files using Gherkin.These files contain scenarios that define how the system should behave.

This stage ensures that both technical and non-technical team members can read and validate the expected behavior before writing any code.

Below are the detailed Gherkin statements to describe the business scenario of “As a customer, I want to be able to place an online order for products and receive real-time updates on the status of my order”
 

Feature: Online Order Placement and Status Updates

  As a customer,

  I want to be able to place an online order for products

  And receive real-time updates on the status of my order
 

  Scenario: Placing an Online Order

    Given I am a registered customer

    And I am logged in to the online store

    And there are available products for purchase

    When I add a product to my cart

    And I proceed to the checkout process

    And I provide the necessary order details

    And I confirm my order

    Then my order should be successfully placed

    And I should receive an order confirmation email
 

  Scenario: Tracking Order Status

    Given I have placed an order

    And I have received an order confirmation

    When I visit the order tracking page

    Then I should see the current status of my order

    And the status should be updated in real-time
 

  Scenario: Order Status Notification

    Given I have placed an order

    And I have opted to receive order status notifications

    When there is a change in my order status

    Then I should receive a real-time notification

   And the notification should include the updated status of my order

3. Automation Stage

Finally, the written Gherkin scenarios are turned into automated tests. Each of the steps is mapped to their corresponding code section.

Steps To Do BDD in TDD

Test-driven development (TDD) is an iterative process where code quality is guided and continuously improved through tests. The process of TDD is:

1. Define behavior with BDD using Gherkin (Given - When - And - Then)
2. Write tests (even before writing code). The idea is to run these tests and watch them fail. After that, we write code until the tests pass, essentially using the tests to drive the development process.
3. Run the tests and watch them initially fail because the code doesn't exist yet.
4. Write code. Execute unit tests again until the tests pass.
5. Refactor the existing code to pass the tests while improving design, readability, and maintainability. 

What Are BDD Testing Frameworks?

BDD testing frameworks are tools that provide support for implementing BDD practices and automating BDD tests. They bridge the gap between business requirements and test automation.

Popular BDD Testing Frameworks

1. Cucumber

Cucumber is a highly popular BDD testing framework. Initially developed in Ruby, it now supports various programming languages, including Java and JavaScript. Its popularity remains strong within the Ruby developer community due to its familiarity. Some organizations combine Cucumber with Selenium to achieve reliable test automation with an emphasis on plain language. This approach fosters shared understanding, improved collaboration, and scalable web testing across multiple browsers. 

Read More: Cucumber Testing: A Detailed Guide

2. SpecFlow

SpecFlow is a highly sought-after BDD framework for .NET. It offers two versions: open-source and premium (SpecFlow+). The open-source version requires a separate unit test runner like MSTest or Unit to execute test scenarios. In contrast, SpecFlow+ includes a built-in runner suitable for BDD testing. The premium version of SpecFlow also provides additional features such as Microsoft Excel integrations, living documentation, and premium support.

3. Quantum

Quantum, an open-source BDD testing framework developed by Perfecto, offers organizations a powerful option for expanding automation efforts. Quantum enables stable execution of BDD automated tests in the cloud, ensuring reliability on clean and secure Android/iOS devices and desktop browsers. Users can leverage all the familiar features of Cucumber BDD, including data tables, scenario outlines, examples, and backgrounds.

4. JBehave

JBehave is a renowned BDD framework for Java and other JVM languages like Groovy, Kotlin, and Scala. As one of the original BDD frameworks, JBehave holds a strong reputation among developers and test engineers. However, it's worth mentioning that JBehave lacks certain common Gherkin features. Teams seeking a fully compliant Java or JVM-language BDD framework often include Cucumber-JVM in their evaluation.

How To Do BDD Testing with Katalon and Cucumber? 

Katalon is a comprehensive QA solution that allows teams to create automation tests for web, API, and mobile, execute them on cloud across a wide range of browsers, then generate in-depth reporting.

Katalon supports BDD testing on Cucumber, allowing testers to get the best of both worlds, leveraging the BDD capabilities of Cucumber while utilizing the rich features provided by Katalon:

• Import BDD feature files into Katalon to leverage its centralized test management features
• Easily create test scripts with Katalon’s low-code test authoring features
• Link BDD steps with test scripts to track test results
• Generate detailed test reports in BDD style

After downloading Katalon Studio, simply navigate to File > New > BDD Feature File to create a Cucumber feature file in Katalon.

Give your feature file a name. If you check the “Generate sample feature file template,” a full BDD script template written in Gherkin will be created for you to freely edit.

Here is a simple Gherkin scenario as shown below:

Scenario: Login functionality

    Given I navigate to the login page

    When I enter my username

    And I enter my password

    And I click on the login button

   Then I should be logged in successfully

At this stage, you should see that there is a yellow highlight on each step in the feature file. This occurs because we have not yet created the step definition or test script for each step (i.e., missing glue code – small pieces of code or scripts that connect two technologies together, which are Cucumber and Katalon in this context).

Therefore, the next step involves creating the step definition in the step file. In the left sidebar, navigate to Include > features > scripts > groovy > (default package). Here you can right click, select New > Step Definition and create a Groovy script.

As you can see, each of the BDD steps above have been linked with its corresponding test definition.

After that you can start leveraging the fast test authoring features of Katalon to transform the BDD feature file into a full test script within seconds. There are two notable methods:

1. Built-in keywords: these are essentially code snippets that you can drag and drop to construct the test case.
2. Record-and-Playback: this feature records the sequence of actions on your screen, retrieves the xPath of the objects you interact with, and turns them into a Selenium script that can be re-executed across multiple environments. Simply put in your destination URL, choose the browser and run.
   

Read more: Cucumber BDD Automation Testing With Katalon

Although these are low-code features, Katalon still allows you to view the full script, and you can complete the functions in the step definition file with the respective newly generated code. Finally, navigate to the top toolbar and click Run. Your device will run automatically and after the test is finished you can see the BDD test results in Katalon TestOps.

It is easy to see how the capabilities of Cucumber are significantly expanded with Katalon:

• Low code, fast test authoring instead of coding test scripts from scratch
• Coding mode available for extra customization of test scripts
• Cross-browser testing and execution for higher test coverage
• Katalon test scripts can be maintained and easily updated through centralized management system, which is less resource intensive than Selenium scripts
• Detailed test result generation in BDD style
  
  

Try BDD Testing With Katalon

BDD Testing FAQs

1. What are the key differences between BDD and TDD?

Here is a table that compares the differences between BDD and TDD:
 

Read More: TDD vs BDD: A Comparison

2. Can BDD Testing be used for non-Agile projects?

Yes, BDD testing can be used for non-agile projects. Although BDD is often associated with Agile methodologies like Scrum or Kanban, its principles and practices can be applied to any software development project, regardless of the development methodology being followed.
 

The key benefits of BDD, such as improved communication, shared understanding, and the ability to drive development based on business requirements, can be highly valuable in non-agile projects. BDD helps to ensure that the system meets the desired behavior and provides clear and unambiguous documentation of the system's functionality.

3. Can BDD Testing be combined with other testing approaches?

Yes, since BDD testing itself is a way to improve collaboration in testing, it can be combined with many other testing approaches. 

4. How does BDD Testing enhance collaboration among team members/stakeholders?

BDD’s distinguishing feature lies in its capacity to integrate the behaviors and actions of stakeholders into the development process, ensuring the creation of software that aligns with their expectations and requirements.
 

BDD fosters collaboration, facilitating a shared understanding of the software's functionalities and necessities, while eliminating ambiguities and misunderstandings by emphasizing the use of clear language throughout the development process.

Start Testing With Katalon