Software development is complicated, yet the effort does not always yield the expected results for the owner and users.

Sometimes, the developer doesn’t have a complete idea of the product, probably due to poor communication from the client.

For instance, if a developer doesn’t understand a businesses’ primary needs, they prioritize the unnecessary features or even create a wrong product.

Business-Driven Development (BDD) solves this.

BDD is the collaboration between businesses, technical teams, and developers to create useful business software.

It shows how an application should work from actual examples to help developers nail perfect deliverables in one go.

It gives a complete picture of the physical, technical, and functional details of a product.

Table of Contents

1. History of BDD
2. Major advantages of BDD
3. Parts of BDD
4. Beginning the BDD Journey
5. Impact Mapping
6. Ubiquitous Language
7. BDD Examples
8. Creating a BDD Feature
9. The Three Amigos

History of BDD

What is BDD? 

BDD (Behavior Driven Development) is a by-product of TTD (Test Driven Development). It runs with a non-complex domain-specific scripting language (DSL).

DSLs change well-ordered statements in natural language into executable tests. The natural language can be understood by both tech-oriented and non-technical people, bridging the gap between them.

BDD was Introduced in 2006 by Dan North—a London-based expert technology and organizational consultant.

It is an agile software development practice, which allows software developers, testers, and business owners to work together and produce the best possible software solutions for businesses.

It was initially introduced as a confusion-clearing system.

What is The Scope of  BDD? 

Before running a software test, BDD expects the software developer and testers to know:

• Where to begin the process
• What should be tested and what should not be tested
• How much often to test
• What to name the tests
• How to figure out the reason for test failure

Typically, BDD rethinks a unit and acceptance testing approach to avoid the most common issues. 

Most BDD examples suggest writing unit test names as whole sentences, beginning with a conditional verb, such as “should” in the English language.

It suggests that the word be written in clear business terms and order of business value. 

While writing acceptance tests, they should come in the standard agile framework of a user story, i.e. [stakeholder/actor] I want a [capability/feature] yielding a [benefit].

It’s also essential to understand the user story for the project.

A user story in software development and project management is a non-formal way of using natural language to describe the features of a software system. 

These features are written from an end user’s point of view and documented in project management software or index cards. 

Different stakeholders, whether managers, development teams, clients, or users, can write user stories, but it all depends on the nature of the project in consideration.

People used BDD frameworks for collaboration and communication between software developers, quality assurance, and business or non-technical participants in a software development project. 

During a 2013 interview, the founder of BDD, Dan North, defined it as a system that uses examples to talk through an application’s behavior and have conversations about those examples. 

Dan North first created a BDD framework called JBehave, which RBehave succeeded.

RBehave is a framework for Ruby and eventually became part of the RSpec project. It is a framework with limited syntax for define and executing application requirements.

Now we’ve answered the questions, “what is BDD?” Let’s see the advantages.

Advantages of Behavior Driven Development

Here are reasons several developers choose BDD as their preferred testing method:

#1. Great Results

The resulting software design syncs with the business owners’ current requirements through BDD and creates a platform for suitable subsequent ones.

#2. Flexibility

BDD allows for flexibility in new design integration, making the software architecture simpler to manage.

It also allows systems to swiftly adapt to new requirements without compromising the proprietary stability and work balance.

#3. Proper Communication

BDD is excellent for project communication; it makes feedback and tracking the development updates simple and straightforward.

#4. User Satisfaction

The resulting software satisfies users’ needs, which improves the business appraisal and helps to get more customers. 

User-focused development boosts customer loyalty and brand reputation.

#5. Better Understanding

BDD means both tech-oriented and non-techy people can have a thorough insight into the project’s progression. This is because of a common language for everyone involved.

#6. Minimal Cost 

BDD is cost-effective. Hybrid code reduces production risk and maintenance cost. 

When automated acceptance tests run through test-first BDD scenarios, the price is lower than post-automating acceptance tests.

Acceptance Test-Driven Development (ATDD) can be more helpful than splitting development and test automation because it allows teams to share behavioral data easily. 

In contrast, you need much interpretation when teams separate development and test automation.

Also, automating tests from previous scenarios reduces regression errors and the need for manual evaluation and coverage. 

It simplifies the development process and data interpretation.

#7. Efficiency

BDD helps to prioritize important business features to ensure efficient system administration.

It also allows the developers the flexibility to bring in parts of the total design in smaller portions.

#8. A Living Documentation

BDD’s real example gives an evergreen description of the current system behavior.

The result is unified project guidelines for developers. It validates the system before regulatory or third-party changes.

#9. Rapid Iterations

BDD enables a team to work in rapid iterations. It allows for continuous breaking down of users’ problems into fragments for fast development.

Beginning the Business Driven Development Journey

A good software development process helps automate and optimize user behavior, so developers spend more time on what matters. 

Automations expand your customer base, establish stronger brand loyalty, reduce wastage and improve customer experience with fewer resources.

Project delivery in Business-Driven Development is usually in sets of capabilities. 

Capabilities are essential features in software development that help users improve their efficiency. 

A very relatable example is automated telecommunication systems that allow for ease in managing virtual communication resources or automating the order placement process of an eCommerce store.

Business owners need to communicate their business goals and aspirations; this is the most important engineering factor in BDD. They should spell it out in pure business terms for easy understanding.

It’s also important to have an aligned business goal.

An excellent business goal should be SMART, i.e., Specific, Measurable, Attainable, Relevant, and Time-bound. 

It helps the engineer to make the correct decisions through design and development. It also satisfies the business owner and maximizes user satisfaction. 

For instance, let’s take examples of two categories of business goals: one SMART, and the other, “un-SMART.”

Un-SMART example: We will get more customers loyal by improving our checkout process.

SMART example: By including three more automated software features in our checkout process, we plan to increase customer loyalty by 25% within the next four months.

A SMART business goal like the one shown above helps cut down on backs and forths of development.

It also makes room for the evaluation of the business goals for the software solutions.

It ensures that there is a strong connection between business requirements and the resulting software system.

3 Principal BDD Practices

There are three basic practices in conventional BDD, which can be discussed as stages:

• A new user story–a tiny upcoming change to the system–is taken. 

It’s followed by sharing concrete examples of the new functionality, brainstorming, and agreeing on the system requirement. 

• Next, those BDD examples are documented in such an automated system, and they are checked for agreement.
• Lastly, the behavior illustrated by each of those documented examples is executed, beginning with an automated test to act as a guide in the code development process.

The focus is to break down each change into tiny units and perform a rapid iteration, going back up a level each time more information is required. 

Interestingly, each time a new example is automated and implemented, you value to your system, and you’re prepared to respond to feedback.

We summarize these BDD under: 

• Discovery
• Formulation, and 
• Automation.

Those documented examples become beneficial assets with time, enabling your team to make confident and rapid changes to the system.

#1. Discovery

Discovery answers the “What it Could do” question. 

According to Fred Brooks in the Mythical Man-month, one of the most important yet most difficult parts of building software is being precise on what to build.

The BDD team does the test documentation, and engineers do the automated tests. Still, these are only spinoffs of the real deal.

The real deal is creating working and valuable software. And the easiest route to the goal is efficient conversations between the parties taking part in the software delivery process.

Helping teams to communicate adequately, BDD enables the parties involved to minimize how long they spend in meetings and maximize the degree of value contained in the final code.

Structured conversations, also known as discovery workshops that border around real-life examples, help the parties relate with the system from a user’s perspective. 

Discovery workshops are conversations where business and technical people work together to explore, discover, and agree to the best of their ability on the required behavior for a user story.

Such conversations enlighten the team on the needs of the users, the governing rules and integral values of the system, and the scope of the system’s goals.

It could also bear the gaps in understanding team members and need more clarifications to avoid a bottleneck in the project.

A discovery session investigation process also helps the team integrate features in the correct order of priority, all according to users’ perspectives.

The team can postpone low-priority features and work on more essential functionalities to create a more efficient flow.

As a newie to BDD, you might need to begin with discovery. You need to understand and master it to appreciate the other two practices and get the most out of them.

#2. Formulation

The formulation is concerned about “What it should do.” After a practical example is identified from the discovery session, each can now be formulated as structured documentation. 

This provides a quick way to prove that the whole team has a shared understanding of what to build.

Contrary to traditional documentation, a readable system for both humans and computers is used, and there are two main reasons for that.

First, it allows every team member to give feedback on the common goal of the development project.

Second, it enables the team to automate these examples as a guide to develop an all-inclusive software solution for the goals required.

Writing these implementable specifications together as a team aside from providing a shared language also helps the team converse using problem-domain terminology until the code development stage.

#3. Automation

This has to do with “What it really does.” With an executable specification handy, the team is better guided on how to develop the implementation.

By picking the examples bit by bit, the implementation is automated when connected as a test to the system.

If the test doesn’t is unsuccessful, it simply implies the behavior was not implemented.

An implementation code is then developed, and lower-level examples representing the behavior of the internal system components are used for proper guidance.

Those automated examples help the team to keep the development process going.

The automated examples help the team understand what the system is doing when there’s a need to maintain the system later.

They also allow for making changes without destroying the system’s free flow. 

With this repeatable, rapid feedback, the team is freed of a load of manual regression testing, allowing people more time to do essential things like exploratory testing.

Impact Mapping

After getting a short-term project goal, defining it, and choosing a timeline to work with, it’s time to start plans to achieve the goal.

Most often, software development teams add many features to applications in a bid to achieve their goals.

But, stuffing a system with features often doesn’t solve the many problems in development, not to talk of achieving the goals. It has contributed to the failure of many projects. 

A better practice should be to find out how the features will be valuable to the business or the users’ behaviors instead of just trying to integrate as many features as possible.

Impact Mapping is a technique that helps a development team to understand all of the different ways to reach the goal by analyzing users’ behavior.

This produces more authentic software applications that can support a wide range of human behaviors and achieve development goals.

Ubiquitous Language

Ubiquitous language is created by the business and developers to help in conversations about features and discuss examples effectively.

Newbies may mistake it for a technical language, but it’s not. Neither is it a business language. It’s a combination of both.

Accepting each other’s perspectives is key for effective communication between the development parties.

Ubiquitous language is used in BDD to avoid language-based complications. It may be challenging to communicate examples effectively without a shared language.

This does not mean language as in geographical language or dialect, but the language on a contextual and logical basis.

People from different business spheres may have different perspectives on examples made from a one-sided language.

For instance, a small business may use spreadsheets for analyzing processes, but the developers are only familiar with technical maps and diagrams.

That’s why the most adopted and standard format for writing or providing examples is the Given-When-Then format–and the most used form in BDD.

Its structural arrangement is very simple and straight to the point.

• Given: This explains the initial condition or context for the example provided. Given steps should be written in past or present-perfect tense because they stand for an initial state that must already be established.
• When: This describes the action performed by the stakeholder or actor in the system. When steps should be written in the present tense because they represent actively performed actions that are all part of the behavior.
• Then: This describes the outcome required from the action. The present or future tense would be most appropriate for the “Then” steps since they represent the outcome of behaviors.

The Given/When/Then format has gained tremendous popularity because it relates to the usual way people speak.

Business Driven Development Examples

Here are some basic steps to begin using BDD:

1. Begin with your user stories
2. The team must first go through the user stories and write BDD scenarios with the keywords ‘Given,’ ‘When,’ and ‘Then.’ ‘And’ and ‘But’ may be used.
3. Given concerns about the initial conditions. For instance: “Given the credit card is valid.”
4. ‘When’ is the active component. For instance: “When Account Owner requests £40.”
5. Then is the assertive component or outcome. For instance: “Then the machine should dispense £40.”
6. Document the BDD scenarios where every member of the team can see it and have equal access.
7. Automate your BDD scenarios
• When you try to execute for the first time, it will fail because the feature is not yet implemented.
• You may need to learn how to build a test automation framework as automation requires a degree of development skill.
8. Implement the BDD features
9. Execute the automated BDD scenarios to show that the feature has been completed.
10. Repeat the process

BDD uses a domain-specific language known as Gherkin to write software requirements as feature files. Below is a sample Gherkin document:

Feature files are written in the Given-When-Then [GWT] format. Feature files usually consist of Feature Title, Narrative, Background, Scenarios, Steps, and Tags.

Feature: Account Owner withdraws cash

Scenario: Account has insufficient funds

• Given the account balance is £200
• And the card is valid
• And the ATM contains enough cash
• When the Account Owner requests £40
• Then the ATM should dispense £40
• And the account balance should be £160
• And the card should be returned

The most accepted and common way of writing feature files is the GWT (Given-When-Then) format.

Feature files usually contain the feature title, background, narrative, steps, scenarios, and tags. 

Note that the feature file constituents listed are not arranged in their appearance in a BDD feature.

Creating a Business-Driven Development Feature

Features are organized in folders to help you manage your project quickly and efficiently. The description of a part provides the context, and it is usually written like this:

As a {title/role} I want {feature} so that {benefit}

A feature is a format for the user story. There are two components to a feature. They are:

• Feature Title: This is usually a short, straight-to-the-point description of the story in consideration. A title should typically be a sentence that explains the scope of the user story. A feature title example is:

Exchanges and returns go back to inventory.

• Narrative: The narrative goes into more detail about the story with role and benefit. Example:

As an eCommerce business owner,

I want to return goods to inventory when exchanged or returned,

so that I can track inventory.

Example of a narrative;

Adding Scenarios

A scenario is a case that has multiple steps in it. 

Note: A feature file may contain multiple scenarios.

The “given/when/then” vocabulary removes most development ambiguities and makes conversations more efficient.

The acceptance criteria comprise the individual description of each narrative scenario with the Given/When/Then structure. There is no exact formal requirement for writing BDD user stories. 

But BDD insists that every team using it must write their user story in a standardized format that contains each of the elements mentioned above. However, Dan North suggested a format for writing user stories in text.

Title: Account allows 20% discount for customers making their fourth online purchase

As an eCommerce business owner,

I want customers making their fourth purchase on the website to get a 20% discount.

So that I can improve customer loyalty

Scenario 1: Customer “Benny” buys for three times

Given: He is logged in as a registered user

When: Benny tries to checkout the items he purchases

Then: he should see his normal purchase price.

Scenario 2: Customer Jerry purchases for the fourth time online

Given: Jerry is logged in as a registered user

When: Jerry tries to checkout the items he purchases

Then: Jerry should see “Congratulations, you have a 20% discount on your order.”

A previous scenario can be used to create multiple examples. However, it can be very laborious and monotonous to clone scenarios to use different values.

Using parameters and data tables allows you to express these examples in a more concise form.

The Three Amigos

BDD, being a collaborative process, is most effective when the examples are deduced. The common goals are communicated regularly to all the team members.

This provides a platform where they can contribute to the development process throughout and track the progress.

The development process requires the expertise of the parties involved to achieve an excellent software application.

If the whole process is left for the developer or just one team member, the project may turn out lopsided and unsatisfactory.

Otherwise known as a Specification Workshop, the Three Amigos is a system of conversation where the business or product owner and other stakeholders like the developer and the tester discuss the system requirement. 

It allows the business owner, the developer, the tester, and other stakeholders to come together and see the project from each other’s perspectives. 

This is to enhance the development process and produce the best possible product that achieves the system requirement.

Business owners and analysts evaluate risks and help to determine how useful the software should be.

Their contribution to the development system is invaluable for the delivery of valuable software.

Developers, unlike business owners, are concerned with suggesting solutions during the development.

They have so much insight into the degree of detail included in a feature for it to be executable.

Testers probe the solution; they make up the problem space. Their many “What-if” questions cause the team to brainstorm to achieve spot-on solutions to achieve the system requirement.

The goal and values of Business Driven Development will be defeated if the three parties in the team–business owners/analysts, developers, and testers don’t have a meaningful conversation about each feature of the system before kick-starting the project. 

The Three Amigos, specification workshop or example workshop, must occur before the team commits to provide a feature or software product.