BDD in Agile Software Development
Behavior Driven Development (BDD)
“BDD is a way for software teams to work that closes the gap between business people and technical people”
The BDD is defined as a mechanism for software teams to work in a collaborative manner according to the Cucumber website and to bridge the gap between business and technical people in terms of requirements, misunderstandings, and assumptions that can affect the delivery piece.
The way to accomplish it. BDD is a collaborative work culture, which suggests that the specifications are derived from a collaborative effort of business and technical people working together and addressing the issue and seeking a solution to it.
Traditional Waterfall Model
In the traditional waterfall model, the client may notify the business analyst of the model to be developed.
In Typical waterfall model company analyst will begin recording the specifications in the format of the use case. The business analyst will share the specifications with the developers and the testers until the documentation is completed. To create the program, developers will take the specifications and the testers will take the scenario to write the test cases and test automation scripts.
The main problem with this approach is that the developer, the tester, and the business analyst are at high risk of misunderstandings and assumptions. This occurs because the selection of criteria has not taken place in a collaborative manner. This will lead to the application being transmitted slower to the inductors.
Agile with BDD Approach
In order to overcome these threats, BDD plays a crucial role.
- The client will inform the business analyst about the feature that has to be created in the BDD approach. Then the business analyst will call the developers and the testers to discuss the functionality in detail for a meeting called the Three Amigos Session.
- An arrangement can then be made on the specifications they are preparing to produce between the market consultant, developer, and the tester.
- The specifications are called Acceptance Criteria in the BDD terminology and they are usually the bits of small requirements.
As accepted and mentioned earlier, the developer and the tester will take up the acceptance requirements directly and start the phase of production and testing.
The main possibility of misunderstandings and prejudices can also be avoided when doing this.
Three Amigos Sessions
Let’s see a little bit more of the Three Amigos Session now.
The Three Amigos Session is a meeting between the product owner or the company analyst, the developer, and the tester, as we saw in the previous slide, who consider and analyze the customer stories and write them in Gherkin scenarios.
A person who is responsible for determining the scope of the application and for converting the use of stories into a collection of features is the product owner or market analyst.
In contrast, it is up to the tester to come up with the scenarios and edge cases.
It is the duty of the developer to come up with the philosophy to construct the application and foresee any technological difficulty in designing and producing the software.
As an end result, the approval conditions are extracted and Gherkin terminology is used to make it simpler and more comprehensible for both professional and business people to write such scenarios.
I hope you have a quick understanding of the how-to avoid misunderstanding using BDD.
