In this section, we will discuss some Practical Scenarios for BDD.
Business requirement is written in ubiquitous language as below.
In order to (Achieve Something) --> Business Outcome As a (Role) I want to do (Some operation)
I Order to pay online bill payment As a Net banking owner who have Transaction access I want to Navigate to payment section, Enter amount and proceed my payment.
This is the example for defining template for basic requirement. Let’s try to understand this.
In order to (Achieve Something):- Here Achieve something is the business requirement. This is basically what is the business outcome you are getting form the template should be mentioned under this section. For example, in Facebook adding friends the outcome of business is we should be able to add someone in our friend list.
If there are 10 templates defined, then there are 10 business requirement which we should develop as well as test.
Line 2 :
As a (Role):- This indicates what role you need to process to perform the operation. For example, in Banking application based on the access there are many roles like Credit Card role, Admin, Net banking authority etc. So as a what kind of role you need to process to achieve this operation, that kind of role you need to pass under this section.
Line 3 :
I want to: This is the section on which developer wants to focus. This section needs to be developed and tester need to make sure that this functionality is working properly. For example, in case of Adding Facebook friend, we need to write that I want to click on add friend by going to his profile.
In short the above 3 lines are described the business requirement, role who trigger the event and operation. This will clear that what is the requirement, who all are the part of this requirement i.e. Roles and what should be expected output for this requirement.
From the above practical Scenarios, we have got clear picture of feature file, step definition file and overall BDD framework.