Behavior Driven Development (BDD) is a methodology for developing software through continuous example-based communication between developers, QAs and BAs.
The primary purpose of BDD methodology is to improve communication amongst the stakeholders of the project so that each feature is correctly understood by all members of the team before development process starts. This helps to identify key scenarios for each story and also to eradicate ambiguities from requirements.
In BDD, Examples are called Scenarios. Scenarios are written in a special format called Gherkin. The scenarios explain how a given feature should behave in different situations with different input parameters. They are called “Executable Specifications” because Gherkin is structural and it serves both specification and input into automated tests.
Behavior-driven development was developed by Dan North as a response to the issues like:
• Where to start the process?
• What to test and what not to test?
• What to call the tests?
• How to understand why a test fails?At the heart of BDD is a changing approach to unit testing and acceptance testing that North came up with while dealing with these issues.
For example, he found that unit test names should be whole sentences starting with the word “should“ and has to be written in order of business value. Acceptance tests should be written using the standard agile framework of a User story:
“As a [role] I want [feature] so that [benefit]”. Acceptance criteria should be written in terms of scenarios and implemented as classes:
Given [initial context],
when [event occurs],
then [ensure some outcomes].
So what are the advantages?
It involves getting stakeholders and delivery team with different perspectives onto the same page and ensuring that all have the same expectations.
The goal of BDD is a business readable and domain-specific language that allows you to describe a system’s behavior without explaining how that behavior is implemented.
Tests are written in the form of plain text features descriptions with scenarios typically written before anything else and verified by the non-technical stakeholders. No development skills are required for creating tests as tests are written in the ubiquitous language. Business Analysts can actively participate in the automated test cases review process and give their feedback to enhance them.
BDD helps to focus on the user’s needs and the system’s expected behavior rather than focusing too much on testing the implementation. In some cases, the tests written by the manual tester/client/ business analysts are not good enough for automation. So, some rework may be required to make them suitable for automation.
The concept of BDD is relatively new that is why the support community is not large enough yet. So currently, it might take a little longer to resolve the technical issues or queries.
It engages product teams, business analysts, QA team and developers onto the same page and provides a platform to resolve the differences in points of view. Thus, it ensures that all stakeholders have the same expectations. This cooperation between stakeholders in-turn results in a good and clear set of Acceptance Criteria.
Tools?
Cucumber is a Java framework for BDD, by its support for the particular set of interactions between team members and stakeholders. Cucumber can execute plain-text functional (feature) specifications as automated tests. The language that Cucumber understands is called Gherkin.
Cucumber supports writing specifications in about 30 spoken languages, making it easy to deliver better for teams outside of English-speaking territories or those working on internationally targeted software.
Other features include:
• Integration with all the most popular testing libraries;
• Specifying the behavior looking at the system from the outside;
• Defining executable specifications in different ways like lists, prose and tabular data;
• The plain text files can be stored in any version control system;
• Collaboration and coming up with a good and clear set of Acceptance Criteria.
Here is a simple example
Feature: log into the system. User should be signed into the system when he provides valid username and password
Scenario: Successful login with Valid Credentials
Given User is at the Home Page
And Navigate to LogIn Page
When User enters credentials
| username | password |
| testuser_1 | Test@123 |
And User login into a system
Then user is on the main profile page
How to start with the Behaviour Driven Development?
Firstly, there’s a period of training for your team involved in your requirements documentation — and with no matter, whether you’re working Agile or Waterfall or something else, this approach will work.
Secondly, you have to explain the changes to your developers and QA teams. Educate them on what the changes are going to be, and how to read and interpret the new method of documentation. Plan how you will incorporate this into your code and test case documentation. It’s best to start with a single project and single release, to pilot the process first. Establish some metrics before you start. Were the requirements included faster or slower to document? What about the code? Testing? Were the defects reduced? Explore your existing metrics and set up some measurable ones to make sure that these changes work for you.
Another attractive aspect of this is that if it somehow fails to meet your needs, it’s easy to undo. You go back to writing requirements in an old way. No retooling. No big process rewrites. No retraining. Just write sentences the way you used to do it. Both the costs and risks are very low with BDD compared to many other methodologies out there.
Behavior Driven Development is a worthwhile practice for any software studio to at least evaluate and try, and it has the potential to bring big benefits to your development and software testing programs.
