_edited_edited.png)
Introduction:
BDD stands for Behaviour Driven Development. It’s all about collaboration between Business Teams and Technical Teams. In any Organization, we have Business teams who understands the User Scenarios and the User Modules and how does our users interact with the applications and then we have Technical teams which comprises of developers, testers and automation engineers who do the implementation part. Usually there is a gap between the understanding of both the teams and BDD plays a vital role in bridging this gap. So using a BDD process, we can build a common understanding between the teams on the Behaviour of the application and in this process we can generate a documentation that can be understood by all the teams and Stakeholders. In an Organization, so for any change/addition in the application we create an User story in an Agile Process.
User story is a general explanation of a software feature written from the end user’s perspective. After creating user stories, we do meetings between different teams and go for a discussion on how the System should behave. Examples are created and agreed and approved after the discussion. Finally they are documented in such a way that they can be developed and tested with automation. After that, it will go on a coding phase where implementation is done as per the documentation. We will create automation scenarios/tests in the coding phase which will guide the development. The tests will fail because there’s no code developed and eventually code will be developed to make this automation scenario pass.
BDD Roles and Responsibilities:
In a BDD process, there will be Product Owners, Developers and Testers. Business Analysts(BA) or Product
Owners(PO) will define the problem and the requirements. He is the Person who talks with Business Owner
or Stakeholders of the application and takes the requirements. After that, requirements are documented into user stories. Then the developer decides the technical solution and how it will be implemented. He defines the code addition or changes. The development team writes and implements the code. Tester decides the solution on testing by what scenarios and modules need to be covered . Finally the QA /testing team writes and executes the tests.
There are 3 phases in BDD, they are
Discovery - where we do the discussion on how the system should behave
Formulation - where we have the documented examples
Automation - where coding and automation comes into picture
BDD workflow:
In this process, we can talk about Sprint. It is a short time-boxed period either 1 week or 2 weeks when the team works to achieve a set amount of work. Sprints are based on number of User stories, they can be 2 or 3 User stories or whatever can be completed. Before Sprint period, the requirements and Gherkin will be ready and during Sprint period, Development and Automation happens and there is test execution phase if there are any defects, they will be fixed. After that retesting, regression testing is over and finally validation part and release of the product is done, So, this is how BDD complete workflow looks like in any Organization.
TDD vs BDD:
Both TDD and BDD are the two software development techniques.
TDD stands for Test Driven Development. Here in TDD, the code is driven by tests. Test cases will be written in Programming languages such as Ruby, Java etc.
TDD workflow:
Tests are created
Run the tests(will fail)
Write code to pass the test
Refactor tests to remove redundancies
Due to this Behaviour, TDD sometimes also called as Test First Development, in which we are testing the code while developing it.
BDD is an extension of TDD. Here, we write tests first and then add application code.
The difference is ,tests are explained as a Behaviour of the application and for every functionality we create user stories .
BDD uses the natural language which is simple description of user requirements. So the User stories and Scenarios we create will be in plain English ,which can be easily understood by everyone ,that's the main advantage of BDD.
Everyone in the team both Technical people and Non Technical people, all the teams, all Stakeholders understand the stories and scenarios in BDD and they work in a better way .
BDD Example:
Example is a Login Feature/Functionality.
In User story, as the user should be able to login into the application with valid credentials on the login page. So the User stories have to be in an understandable way. Cucumber introduced a common language called as Gherkin.
User story will be like,
Feature: Check Login Functionality
Scenario:
Given user is in login page
When user enters valid credentials
And clicks on Login Button
Then user is navigated to home page.
Given, When, Then are the keywords in Gherkin Language.
Here,
Given is the precondition , user is in the login page
When is like an action, that is user enters valid username and password
And is some more action
Then is the outcome/expectation, the user is navigated to home page.
This is how the BDD user story/scenario looks like. We can do Automation in a very easy way.
Cucumber:
It's a testing tool that supports Behaviour Driven Development Framework. and Acceptance test Automation. Here the Specifications are written in plain simple English which is defined by Gherkin language. In other words, Gherkin is a language that Cucumber understands.
Key Components :
Feature File
Step Definitions
Test Runner
Conclusion:
BDD focuses on process at the level of features. BDD Feature file consists of one or more Scenarios. These Scenarios are just examples of how the Application should behave. Given-When-Then steps can be reused between Scenarios. Overall, BDD helps in reducing the cost of development.