Hello, everyone. Welcome back. In this video, we will learn what is BDD and how to achieve it.
We will also see how it differs from our traditional waterfall software development life cycle. And we will slightly touch up on the Three Amigos session part as well.
As per the Cucumber website, the BDD is defined as a process for software teams to work in a collaborative fashion and to bridge the gap between business and the technical people with respect to requirements, misunderstandings, and assumptions that might impact the delivery piece.
Now, let's see how to achieve it.
Like I said, BDD is a culture of collaborative work, which means the requirements are derived as a collaborative effort of business and technical people sitting together and discussing about the problem and come up with a solution for it.
Generally, the requirements are not huge.
Rather, they are derived as multiple chunks with limited number of features to be developed. In this way, we can make sure the customer is enjoying the features in a short span of time rather than waiting for months to get a new one.
Also, BDD plays an important role in documentation.
Though Agile supports minimal documentation, BDD will eventually capture the requirements and plays like a bible for the application, having all the requirements in the same place using living documentations concept.
Now, let's see how BDD differs from the waterfall model.
In the traditional waterfall model, the customer will tell the business analyst of the model that has to be built.
Then the business analyst will start documenting the requirements in the use case format. Once the documentation is done, the business analyst will share the requirements with the developers and the testers.
Developers will take the requirements to build the application and the testers will take the scene to write the test cases and automated test scripts.
The major issue with this method is there is a high risk of misunderstandings and assumptions between the developer, tester and the business analyst.
This happens because the requirements gathering didn't happen in a collaborative way. This will lead to the slower delivery of the application to the inducers.
BDD plays a vital role to address these risks.
In the BDD approach, the customer will tell the business analyst about the feature that has to be developed. Then the business analyst will call the developers and the testers for a meeting called the Three Amigos Session to discuss the features in depth.
Then, an agreement will be made between the business analyst, developer and the tester on the requirements that they are planning to deliver.
In BDD terminology, the requirements are called Acceptance Criteria and it will usually be the chunks of tiny requirements.
As it was agreed and discussed earlier, the developer and the tester will directly take the acceptance criteria and start the development and testing process.
Hence by doing this, the major risk of misunderstandings and assumptions can be avoided.
Now let's see a bit more about the Three Amigos Session.
As we saw in the previous slide, the Three Amigos Session is a meeting between the product owner or the business analyst, developer and the tester who consider and discuss the user stories and write them in Gherkin scenarios.
The product owner or the business analyst is a person who's responsible for defining the scope of the application and to translate the use of stories to a set of features.
Whereas, the tester is responsible to come up with the scenarios and the edge cases.
The developer is responsible to come up with the ideology to build the application and predict any technical challenge to develop and deliver the product.
So as an end product, the acceptance criteria derived and to write that scenarios, Gherkin language is used to make it clearer and more understandable by both technical and business people.
I hope you got a brief idea about BDD and Three Amigos Session and in the next video we will directly jump into Cucumber concepts.