Table of contents:

  1. Introduction
  2. What gives business value to the software?
  3. Whats is the main problem?
  4. Describing Requirements
  5. Acceptance Criteria

Introduction

Behavioral Driven Development (BDD) is a software development approach that has evolved from TDD (Test Driven Development). It differs by being written in a shared language, which improves communication between tech and non-tech teams and stakeholders. In both development approaches, tests are written ahead of the code, but in BDD, tests are more user-focused and based on the system’s behaviour.

TDD works satisfactorily, as long as the business owner is familiar with the unit test framework being used and their technical skills are strong enough, which is not always the case. In these circumstances, BDD has the advantage because the test cases can be written in a common language used by the stakeholders such as for example, English. This access to clearer, low-jargon communication is probably the biggest advantage to using BDD, making it possible for collaboration between the technical and non-technical teams to run with improved efficiency.

What gives business value to the software?

The answer is simple: working features. For example when we have a flight management company. One of the business goals may be satisfied customers by providing a simple and convenient way for them to manage their flights. Some features that might help achieve this goal could be:

  • choose a flight
  • change a flight
  • choose a seat on a plane

Communication between the persons that are involved in the same project may bring some problems and misunderstandings. Usually, flow works in this way:

  • the customer tells the business analyst how some new feature must work
  • the business analyst translates the customer's requiremenrs into a set of requiremnets for the developers describing what the software should do
  • the developer translates requirements into code, and unit tests in order to implement new feature
  • the tester translates the requirements into test cases and uses them to verify that the new feature meets tje requirements

Whats is the main problem?

There are many opportunities for information to be lost, be misunderstood or be ignored. Chances are, the new modern staff may not do exactly what has been initially required.In order to address the business goals, the business analyst works with the customer to decide what software features will be able to achieve these goals. These features are high-level requirements, for example:

  • provide the way for customer to choose for a few alternative routes to the destination
  • provide customer to choose the optimal route to destination

These features need to be broken into stories. The stories might look like:

  • find the route between source and destination with smallest number of flight changes
  • find the quickest route between source and destination

Stories need to be described in terms of concrete examples, these ones becoming the acceptance criteria for the story. Acceptance criteria may be expressed in BDD style in a way that can be automated later. The keywords are:

  • GIVEN
  • WHEN
  • THEN

As an example, we may present the following acceptance criteria:

Given the flight operated by comapny X
When I want to find the quickest route from Warsaw to New York on May 2020
Then I will be provided the route Warsaw - Frankfurt - New York, with a known duration

With BDD, we are making a step ahead with TDD, collaboration with the different people involved in a project and providing the language understood by all. The cost of the software creation should be lower, and the development time shorter, as it will prevent from getting lost in the details. It helps not only doing the things right but doing the right things and delivering business value.

Describing Requirements

As a passanger
I want to know the flights for a given destintaion within a given period of time
So that I can choose the flight(s) that suit(s) my needs

Or:

As a passanger
I want to be able to change my initial flight(s) to different one(s)
So that I can follow the changes of my schedule

So the application should provide the passenger with the possibility to interactively make these actions: choose a flight, change a flight, calculate an optional route.

Diagram
Diagram

Expressinf a story in a UML sequence diagram, we see that the passanger uses the application to find the flight. The application is quering the database, then takes the information that has been provided and sent report back to the passanger.

Acceptance Criteria

Practical examples are used as acceptance criteria. The acceptance criteria represent what will satisfy stakeholders in order to agree that the application is working the way it is supposed to do In BDD, the definition of acceptance criteria is made using the: given, when, then keywords:

  • Given <a contetxt>
  • When <something happens>
  • Then <some result is expected>

For example:

Given the flights operators bt the company
When I want to travel from Warsaw to London next Wednesday
Then I should be provided 2 possible flights: 11:30 and 20:14

Reference:

  1. Behavior Driven Development Vol. 2
  2. Behavior Driven Development Vol. 3
  3. Behavioral Driven Development
  4. Test-driven development
  5. Acceptance testing
  6. User story

My site is free of ads and trackers. Was this post helpful to you? Why not BuyMeACoffee