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 behavior.

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?

Answare is simple: working features. For example when we have a flight management comapny. One of business goals may be satisfy customers by providing a simple and convinient way for them to manage thair flights. Some feautures that might help achieve this goal could be:

  • choose a flight
  • change a flight
  • choose a seat into a plane

Communitcaion between the persons that are involved into the same project may bring some to problems and misundersantngs. 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 menay 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 adress the business goals, the business analyst works with the customer to decide what software features will be able to achive these goals. These features are high-level requrements, 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 BDD style in the 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, colaboration with the differnt people involved into a project and providing the language understood by all. The cost of the software creation should be lower, and the the develpment time shorter, as it will prevent from getting lost into 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 application should provide the passanger the possibility to interactively make these actions: choose a flight, change a flight, calulate 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

Partical examples are used as acceptance criteria. The accepnatce criteria represents wgat will satisfy stakeholders in order to agree that the application ia 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. Behavioral Driven Development
  2. Test-driven development
  3. Acceptance testing
  4. User story