BDD 101: Introduction to BDD

What is BDD?

Behavior-Driven Development (BDD) is a way of working on software development that involves different team members collaborating. It’s not a tool or a specific type of testing. BDD was created to help address the problem of unclear requirements and misunderstandings between the people who request software and those who build it.

BDD is similar to Test-Driven Development (TDD), but instead of only developers writing unit tests, the whole team writes tests that describe the desired behavior of the software feature. BDD focuses on defining the expected behavior of a feature from the very beginning using realistic examples, instead of vague technical language. These examples serve as the requirements or acceptance criteria before the feature is built and as test cases or scenarios after development.

Gherkin is a popular language for writing formal behavior specifications in BDD. It uses “Given-When-Then” scenarios to describe the behavior of a feature. BDD scenarios are easy to write and read since they are written in plain English. BDD helps keep developers and QA teams focused on delivering what the product owner wants.

What is a Behavior? Why It’s Important?

Behavior is how a product or feature operates. It’s defined as a scenario of inputs, actions, and output. A product or feature exhibits countless behaviors. Identifying behaviors individually brings clarity and simplicity. It also helps explain how behavior is related. Check the example below.

• Log in to a web page
• Clicking the link on the navigation bar
• Submit a form
• Receive expected error

Separating those individual behaviors make it easy to define a system without unnecessary repetition. For example, there may be multiple ways to navigate to the same page.

Search from a text field and searching directly from a URL parameter both lead to the same result page

What are Three Amigos?

When a new feature is to be implemented, a group of people with different roles — often called the “three amigos” — get together to discuss and define the requirements. This group typically includes business analysts, programmers, and testers. They work collaboratively to come up with concrete examples of how the software should behave. To document these examples, they write them down in a format called Cucumber Scenarios. This helps to ensure that everyone has a clear understanding of what needs to be built, and serves as a starting point for writing the code that will make the feature a reality.

What are the Benefits of Using BDD?

There are a lot of awesome benefits to using BDD. BDD improves the development process in several ways :

Benefit of using BDD Approach

Where do I Start and How to Start It?

When starting a new product or feature, it’s best to begin with BDD. This means creating scenarios that clearly define the expected behaviors of the product, with each scenario focused on one specific thing. To avoid ambiguity, behaviors are described in plain language, and any uncertainties can be clarified with Example Mapping. By doing this, everyone involved in the development process can be on the same page, making it easier to collaborate and ensure that the final product meets everyone’s expectations.

Behavior-Driven Development has two key objectives: improving collaboration and automation. However, it can be challenging to know where to start and which scenarios to write when working together.

One technique that can make collaboration easier in Behavior-Driven Development is “Example Mapping,” a practice developed by the Cucumber team. To use Example Mapping, all you need is a pack of index cards and a big table.

1. write the story being discussed on a yellow card at the top of the table.
2. write a rule for each known acceptance criterion on a blue card under the story.
3. write each example for a rule on a green card.
4. write each open question on a red card to discuss later.

By following this process, the team can quickly see if a story is too big or needs further refinement. The engineers can easily turn the example cards into Gherkin scenarios, and any questions can be assigned to owners to get answers. This process provides clear, fast feedback for stories and should take about 25 minutes per story.

Collaborative BDD Approach that Empowering Dev, QA, and Product Teams for Effective Software Delivery in BerandaToko

Define User Stories

• Product owner and stakeholders work together to define user stories that capture the desired behavior and value of the software.
• User stories should follow the “As a [Role], I want [Feature] so that [Benefit]” format to clearly communicate the intended behavior and purpose.

Example of User stories in PRD Beranda Toko

Collaborative Discussions

• Product owner, Dev, and QA team members collaborate in a grooming session to discuss the user stories in detail.
• Team will identifies and clarifies acceptance criteria, examples, and scenarios that describe the expected behavior from a user’s perspective.
• The discussion aim to reach a shared understanding among all team members.

Create a Feature Files

• QA team members write feature files using a BDD framework based on the result from discussion.
• Feature file contain high-level scenarios written in natural language format using Given-When-Then syntax.
• Scenarios describe the expected behavior and serve as executable specifications that guide development and testing.

Example of Feature file that QA Beranda Toko created in their framework

Implement Step Definitions

• Dev collaborates with QA team members to implement step definitions for the scenarios in the Feature file.
• Step definitions are code snippets that map the steps in the Feature files to the corresponding application code.
• Dev and QA teams member work closely to ensure the step definitions accurately reflect the intended behavior.

Example of step definitions that QA Beranda Toko created in their framework

Iterative Development

• Dev follows an imperative development approach, implementing code in small increments.
• They focus on making each scenarios to be passed by writing the necessary code and ensuring it fulfills the acceptance criteria.
• Regular collaboration and communication with the QA team and Product owner would help address questions, provide clarifications and validate the implementation.

Test Automation

• QA team members create automated test based on the Feature file and step definitions.
• These tests serve as living documentation and are executed to validate the behavior of the system against the defined scenarios.
• Automated tests are run frequently during development to catch regressions and ensure ongoing adherence to the desired behavior.

Continuous Feedback Loop

• Throughout the development process, Product owners, Dev, and QA team members continuously communicate and provide feedback.
• Product owners review the implemented feature and validate if they meet the desired behavior.
• QA team members provide feedback on scenarios, step definitions, and test coverage. Ensuring thorough testing of the system.

By implementing BDD, the collaboration between Dev, QA, and Product owners team member is strengthened. The shared understanding, clear specifications, and iterative development process foster effective communication, reduce misunderstandings, and enable faster feedback cycles. This collaborative approach ultimately helps deliver software that aligns with the desired behavior and meets customer expectations and experiences.