BDD - An Art

Q. What Is BDD ?

Q. Why is there so much confusion around BDD?

Q. How different it is from TDD?

Q. Why should we do it?

Q. What is the outcome / benefits of following this approach?

This are some of the questions that were thrown at me when I first proposed BDD at my workspace. And rightly so. I myself had just theoretical / bookish assumptions about this new approach.

But it fascinated me as a tester. Why?

As a tester, the primary role expected of me is to test the code that was delivered to me in build and see if the expected result and actual result are the same. May that be manual or automation.

Coming Agile and TDD, I have been more involved in writing scenarios along with developer before starting development. This means I have a better understanding (with developer and myself being on same page with a specific requirement).

But there are still unknowns.

What ideas did stakeholders have when this requirement became a necessity?

What information / understanding did product owner have when he decided to fund this requirement?

What value did this functionality found the business analyst eye when he wrote the user story?

Maybe developer and me has some more prospective of how this piece of functionality would really work against the efforts we would put in? We may mentioned this in our standup's but over passesse of time this may slip through the crack. Are we comfortable enough to keep on chasing it? Or Maybe just give up in frustration.

Is BDD answer to my question?

Maybe Yes, Maybe No.

Depending on what your circumstances / project requirements are and most important how are you planning to implement it and practice it.

Let us get a bit of understanding of this art which is called BDD.

BDD or Behavior-driven development is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.

In practice, behavior-driven development may be similar to test-driven development when all stakeholders have programming knowledge and skills.

However, in many organizations, BDD offers the ability to enlarge the pool of input and feedback to include business stakeholders and end users who may have little software development knowledge.

Because of this expanded feedback loop, BDD may more readily be used in continuous integration and continuous delivery environments.

BDD (Behaviour Driven Development) is a synthesis and refinement of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development).

BDD is not about coding or testing, but more about having conversations with stakeholders in such a way that it will uncover and clarify requirements.