_edited_edited.png)
Whats BDD?
BDD is an agile development process that helps build a common understanding on how the system should behave and helps create a common documentation that can be understood by all the teams and stakeholders. It is an extension of the test driven development (TDD). It focuses on collaboration between the business team and the technical team.
Test Driven Development (TDD) is a software development method in which test cases are written in a way to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and making code simple and bug-free. Unlike in TDD in BDD the tests are based on system behavior.
Usually BDD is a 3 step iterative process.
USER STORY:
In any organization a typical BDD process starts with creating a user story. For any new change or enhancement a user story is created. A user story is informal, general explanation of a software feature written from the perspective of the end user.
For example ,
Application -Booking movie tickets online.
The user story that needs to be worked on is
When a user selects the movie and navigates to the payment process, keep the seats blocked until the process is completed or canceled.
DISCOVERY:
The team first takes a small user story and meets to explore on how the system should behave.
The team usually consists of representatives from the business team and the technical team.
Business team comprises of people who understand the business more from an user perspective like the BA or project manager.
Technical team comprises of people responsible for implementation like the developers, automation engineers and the testers.
It is also called as 3 Amigos meeting
(Meeting of people from different teams or different disciplines)
1.Product owner/Business analyst
2.Developer
3.Tester
Usually there is a gap in communication between business team and the technical team and BDD is all about bridging the gap. It helps build a common understanding on how the application should behave and helps create a common documentation that can be understood by all the teams and the stakeholders.
Outcome of this phase is an agreed behavior of the system.
FORMULATION:
In formulation phase the agreed examples are formulated into business readable and executable scenarios. The concrete examples can later be automated.
Gherkin is the specification language utilized to write the scenarios. Its a business readable language which describes business behavior without getting into implementation details.
It helps to breakdown story into atomic action.
Keeps the format consistent.
Makes it easier to understand for all.
Helps in automating the scenario.
Some of the tools used for automating with the scenario are Cucumber, JBehave and Behat.
Gherkin Syntax:
Feature: Title of the Scenario
Given: Precondition
When: Action or trigger.
And: Some more of previous type.
Then: Expected result
Example
Feature: Movie ticket booking.
Given the user has selected the movie
When the user clicks on the payment
Then keep the seats blocked until user completes or cancels the transaction.
Outcome: Documented business readable and executable scenarios of the system behavior.
AUTOMATION:
In this phase coding is done as per the documented examples to implement the agreed behavior of the system.
Outcome: Code implementation and automated tests.
Thus, BDD is considered to be a smart approach in agile methodology as it helps with collaboration between different teams and the understanding of the business need in simple language.
Kommentare