Table of contents:
- What gives business value to the software?
- Whats is the main problem?
- Describing Requirements
- Acceptance Criteria
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:
As an example, we may present the following acceptance criteria:
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.
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.
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.
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 <a contetxt>
When <something happens>
Then <some result is expected>