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 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:
As an example, we may present the following acceptance criteria:
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.
So application should provide the passanger the possibility to interactively make these actions: choose a flight, change a flight, calulate 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.
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 <a contetxt>
When <something happens>
Then <some result is expected>