Behavior Driven Development - A Collaborative Approach

Behavior Driven Development Methodology has been talk of the town for some time now, and here we are going to look into why it is becoming day by day popular. This blog will cover following points:

Why use BDD?
What is BDD?
How it benefits?
How is it implemented?
Challenges & The take away!

Why use BDD? A little background with problem we have… With new software development world working with more agile and CI/CD processes, it is typically important to reduce cost, time and efforts in each phase of SDLC. The main goal is to understand the business goals of the product and deliver quality with upcoming change requests with minimal turnaround time. Having said that lets us look at a typical approach of requirements flow and development:

In the above scenario there is a lot of chance of miscommunication or misunderstanding of client’s requirements
Moreover if a scenario is missed from a Developer or QA perspective then requirements have to be revisited with BAs
Reducing turnover time for feedbacks and change requests needs to be minimized

BDD answers all these three points in a very subtle way. What is BDD? The approach that addresses the concern above… Behavior Driven Development framework emphasizes the requirements to be written in Gherkin Language which is business or domain driven so putting customer’s requirement as the basic orientation of the whole approach. Any product may be divided into a set of features. And these requirements aka features are collaboratively written by Product owners, BAs, QAs and Developers in English-like language with ‘Given-When-Then’ (GWT) scenarios. These scenarios are further implemented by both developers and testers. Following picture describes this collaborative approach: Typically a Gherkin language is written in Given, When & Then – Scenarios which look something like this:

Scenario: A typical description of a use case with one precise goal
Steps: sequence of Steps in form of
- Given- preconditions are defined or contextual steps are taken to set the test case
- When- one or more event or steps taken
- Then- final outcome expected of the scenario
Examples: Generally a set of concrete data on which scenarios should be iteratively run.

How it benefits? Reasons to go for it… Using BDD gives an edge over other frameworks due to following reasons:

Acceptance criteria is written in a feature driven, easily understandable plain language during planning phase with inputs from all stakeholders of SDLC. No technical jargons yet precise with features and concrete examples.
Development has to be done based on the clear use cases, so no miscommunication as their concerns and queries are already clear.
The feature files directly serve as test scenarios and their steps can be directly implemented into step definition files in automation scripts
Time & effort loss of analyzing requirements by developers and testers is cut short
Test cases may be directly derived from feature file steps and set of examples given, hence its implementation is easy and does not require any extra .csv or excel file for test data.
Reusability of steps defined once throughout the framework by importing scenarios and relevant feature files as steps act as fixtures.
Automated test suites on one hand validate the software on each build or as required and provide the updated technical and functional documentation on another, so turnaround time and cost of maintenance goes down.
Unlike TDD and ATDD the development is not test driven but rather business logic driven.

How is it implemented? An Example would be the best way to explain… There are many frameworks through which this is implemented, to name a few:

Cucumber
Lettuce
JBehave
Aloe
Pytest-BDD

Let us take the most common feature of simple login page as the example. So a typical feature file would be: Acceptance Criteria: Feature: My Articles Login Page Given I am on My Articles Login Page When I enter admin username and password And I click on Login Then I am logged in successfully And I am able to see message “Welcome, you have all administrative rights” Given I am on My Articles Login Page When I enter reader username and password And I click on Login Then I am logged in successfully And I am able to see message “Welcome reader! Happy reading” Given I am on My Articles Login Page When I enter blank username or password And I click on Login Then I am not logged in And I am able to see message “Sorry, username and/or password cannot be blank” Given I am on My Articles Login Page When I enter invalid username and password And I click on Login Then I am not logged in And I am able to see message “Sorry, you have entered wrong username and/or password” Implemented feature file (my_login.feature) might look like: Feature: My Login Page Scenario: User is able to login with valid credentials Given I am on my web login page When I enter <username> and <password> And I click on Login Then I am logged in successfully And I am able to see <message> Examples: | username | password | message| | admin | ad_p@ss1234 | “Welcome, you have all administrative rights” | | reader | re@der123# | “Welcome reader! Happy reading”| Scenario: User is not able to login with invalid or blank credentials Given I am on my web login page When I enter <username> and <password> And I click on Login Then I am not logged in And I am able to see <message> Examples: | username | password | message| | “admin” | “re@der123#” | “Sorry, you have entered wrong username and/or password” | | “rader” | “re@der123#” | “Sorry, you have entered wrong username and/or password” | | “reader” | “” | “Sorry, username and/or password cannot be blank” | | “”| “” | “Sorry, username and/or password cannot be blank” | | “”| “re@der123#” | “Sorry, username and/or password cannot be blank” | Presently we are using ‘Pytest-BDD’ framework and a typical step definition file implemented for testing might look like: my_login_step_def.py @scenario(“path\my_login.feature”) @given(“I am on my web login page”) def i_am_on_my_web_login_page() #code for any prerequisite like open browser @when(“I enter <username> and <password>”) def i_enter_username_password(username, password) #code for entering username and password @when(“I click on Login”) def i_click_on_login() #code for clicking on login @then(“I am not logged in”) def i_am_not_logged_in() #code for verifying the user is still on login page @then(“I am logged in successfully”) def i_am_logged_in_successfully() #code for verifying the user is successfully logged in and move to home @then(“I am able to see <message>”) def i_am_able_to_see_message(message) #code to verify the message *Note here we don’t have to write full functions again, same steps are reusable for multiple scenarios over multiple feature files and data is passed from feature files itself in form of ‘Examples’, as multiple iterations of a scenario will run over each row of data set in ‘Examples’. Some Key Findings… Findings suggest that around 30% of major defects were reduced as edge cases scenarios, and application wide standard scenarios were discussed in planning phase with business itself, so time and effort were reduced both at developer and QA end; this results to faster delivery, for example, normally the feature that can take 3 sprint to get completed, can get deployed to production in 2 sprints. Challenges & The take away… BDD framework derives its strength from feature driven, plain English-like language scenarios, and collaborative approach and this has its challenges related to it.

As discussed above, BDD is business logic driven, hence needs more engagement from people on business side, which is a typical challenge sometimes.
In terms of plain language usage, if the scenarios are poorly written then maintenance becomes tedious and time taking.
And most importantly, this framework cannot be used where business, development and testing teams work in a loosely coupled manner and have minimal interactions on their progress and update.

To conclude, BDD is a collaborative way of development which can be used in Agile and Iterative Developments Cycles, with business groups actively taking part and creating requirements in a collaborative manner. At Xoriant, we are already working on this framework with some of our clients and this has proved to be efficient. So, we would like to recommend BDD as it helps us to ensure on-time quality delivery and also does a value add:

By reducing costs and wastage of time & efforts by avoiding miscommunication.
Focusing on business features and ensure all use cases are covered.
Ensures faster changes and releases as testing efforts are moved more towards automation.

Hope this blog helps you understand BDD framework better. We will come up soon with a comparison with Pytest-BDD and Aloe frameworks. Keep watching. Happy Learning!! References: https://media.readthedocs.org/pdf/pytest-bdd/latest/pytest-bdd.pdf http://aloe.readthedocs.io/en/latest/ https://jenisys.github.io/behave.example/