What BDD is all about?

Most of us would have already heard this often in our circles that BDD is Behaviour Driven Development but probably did not find time to probe more into what exactly BDD is all about and how this concept helps the overall development process.

Lets begin with what BDD is NOT supposed to be:

  • BDD is not about tools. Though BDD is supported by tools it should not be that tools control the way BDD is implemented.
  • BDD is not only about testing. It involves everyone playing a role in SDLC and not just STLC.
  • BDD is all about specifications Not Exactly!! It can be a specification based but it can be also a problem which the client needs us to solve so he may put it in his own comfortable way of describing the problem which may then put into specifications by the team comprising of Dev, BA and QA

Now lets delve into BDD

BDD is supposed to be more business friendly where the client will actually describe what exactly he needs.

For e.g. A client who is into garment manufacturing business wants to develop a website so that he has an online presence to advertise his products and can expand internationally.

So a team comprising of Dev, BA and QA get together and start COLLABORATING with the Client

Yes BDD is all about COLLABORATION.

So the client who is a non-IT person will just say that he wants to expand business, he doesn’t understand what are the nitty gritty of putting up a website. So to put his requirement into a user story will be like this

User Story 1:

“As a garment manufacturer, I need a website so that i can have an online presence and expand my business internationally.”

The Dev, BA and now QA (3 Amigos) will now get into action mode and start collaborating to discuss the various technical aspects of putting up a website. Each role will put their ideas from their perspective with an overall objective of building a right solution and come up with features.

Features are nothing but a user story broken down into finer details. For e.g features for the above story will be

  1. Home Page? What will my Home Page display?
  2. Search for products?
  3. Can i buy products from website? If yes, then Buy will be a feature?
  4. Display of Categories. What categories will be displayed?
  5. Do i need a login? If Buying from a website is an option then yes I need a login as well?

And so the list goes on…

Lets take the feature “Search for products”

Should we ask the client to write the specifications? No because he doesn’t understand what do we mean by specifications. So we will write the specifications. The specifications may be as follows

“As a visitor to the website I should be able to search for products which are listed in the website”

Now the 3 Amigos will brainstorm again and create various scenarios from here:

  1. What kind of keywords will be used to search the products?
  2. How the results will be displayed? Will it have images? Will it show price? Will the image expand when i mouseover on the image?
  3. Will the results be displayed sorted by price or by rating by default?
  4. How many results will be displayed in a singe page? 10? 25? 50? Or will the page load for more results as the user scrolls down (Like Amazon etc)

For each scenario above, the BA is thinking whether it is satisfying the client requirements? The Dev is thinking from a technical implementation perspective and QA is thinking from the edge cases which will be required.

So we will now expand scenarios from here in a more testable format. BDD has evolved from TDD i.e Test First so having a feature written in a testable format helps

So to put the 1st scenario in a more test friendly format i can have my first test as follows:

As a website user, if i search for jeans i should get all the products related to jeans

If i combine more scenarios i can expand my test as follows

As a website user, if i search for jeans, I should get all the products related to jeans and each page should show 25 products initially with an image which should be clickable to show a bigger image

We have just tried to put a solution to a basic problem a client is having and with cognitive abilities of the 3 Amigos and collaboration between them we are building our specifications right from the requirements. And the specifications are in the form of a test which client understands by reading the test in a more

And we have already started writing tests in BDD fashion. And the output is clear – an improved communication happening between BA, DEV and QA and they have successfully put their thoughts to develop a full non-abstract specification from a basic client requirement. Hence we say that Agile and BDD go hand in hand!!

We haven’t still introduced tools yet and we have started implemented BDD already!!!

You can now writing blogs on BDD and get it published by participating in Series 2 of #blogATAthon – a blog writing competition from Agile Testing Alliance. After the successful Series 1 on Selenium, Series 2 will be all about BDD. Come, be part of #blogATAthon. Visit https://blogatahon.agiletestingalliance.org/ for more details

References for the above post:

  1. https://www.thoughtworks.com/insights/blog/3-misconceptions-about-bdd
  2. “3 Amigos” from Specification By Example by Gojko Adzic

Leave a Reply