I'm currently working on Agile Project and we have starting to implement BDD as part of it. To do so, I need to present a slide with advantages of BDD. I can see many sites including StackOverflow has the answer, but i'm keen on getting the benefits role wise -

Product Owner : Business Analyst : Developer : Tester :

Appreciate your help in advance.

closed as unclear what you're asking by dzieciou, IAmMilinPatel, Bharat Mane, ECiurleo, Kate Paulk Jun 21 '16 at 11:56

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • So is your question "What is the elevator pitch for BDD"? – corsiKa Jun 22 '16 at 17:47

You probably have read that BDD is not about testing, but about improving communication.

In software development, there are a manifold of ways to express the same thing; and some fit better for each role. Given that, it is common for a project to have many documents expressing the same thing. This cause two problems:

  • When requirements change, all these documents need to be updated;
  • Some documents are "unreadable" for some people - because the notation and language is focused for other people.

BDD - Gherk language, for example - tries to mitigate this problem by creating a simplistic unique source of truth, readable by anyone. Giving unique tags for each scenario, any individual in a team can raise questions about a particular behaviour in the system.

The scenario-based requirements in BDD help:

  • Designers and POs express their needs;
  • Developers and testers to early check if the system if the behaviour (main flow and alternatives) are as expected.

This does not mean that other documents (as wireframes) can not be used, but they should always be linked in the BDD documents (because it is the single source of truth).

In summary, BDD helps to work with two principles of Agile:

  • Embrancing the changes;
  • Communication.

BDD Tests

As many things around us - there is more hype around BDD than what it deserves. BDD was born as a way of naming your tests clearer: instead of saying that you test this-and-that you're saying it-should-work-this-and-that. And this is a great idea since it makes it clear about the purpose of the test and it allows the test to be shared with not-so-technical people.

BDD Methodology

After a while BDD was turned into a methodology where everyone is using the same language. The idea was borrowed from DDD where the vocabulary used by all team members is the same. But BDD tried to mimic this in a different way - it tried to come up with a notation that everyone uses. The benefits of this were not as clear and most of the attempts to implement a full-blown BDD fail in today's projects. Especially when it comes to Given-When-Then style:

  • BAs have to write more text. Often BAs have to write a lot, but with BDD they have to write even more. As a BA Given-When-Then is the last thing that I would want to use.
  • Developers have to read more (which they often don't do). As a PM I was once asked by developers not to use this format because of its verbosity.

So while the benefits of writing easy-to-understand tests is a very good idea, the rest of the BDD is questionable.

BDD Tools

There are several types of tools that can be used for BDD-style testing:

  • JBehave-like frameworks (Cucumber-[js]-[JVM], SpecFlow, Behave, etc.). These are very cumbersome tools since they have additional files to maintain which complicates the maintenance and spoils the Test Data Management (which itself complicates maintenance by an order of magnitude).
  • RSpec-like frameworks (Mocha/Jasmine, describe_it, etc). These are much easier to write and maintain since they are still code but they support additional features to facilitate BDD. They also use a much shorter notation - Describe-It. Though for very complicated scenarios Given-When-Then fits better as for me.
  • Spock, easyb - they are trying to use Given-When-Then syntax implementing it right in the code. Since it's still code its maintenance is still much easier.
  • JUnit/TestNG - these are plain old testing frameworks that don't actually facilitate BDD in any special way. But you still can name and write these tests in an understandable way.


While BDD may seem enticing, you should always make decisions that are good for your project. If you can't find real pragmatic benefits from the tool, you need to question its usefulness. What's really helping the project is a team of professionals. They can make any tool work. But the tool won't make any change if the team is not ready for it.


I don't try to differentiate between BDD and TDD and believe that they are both about the following:

  • small change
  • constant feedback
  • continual improvement
  • improved communication

and they led to the following benefits:

  • useful functionality based on real needs
  • rapid change for features as needed
  • less artifacts
  • quick turnaround for bug fixing

Not the answer you're looking for? Browse other questions tagged or ask your own question.