Many companies use Behaviour Driven Development as a part of their software development process for automated testing of their business logic. The idea of Behaviour Driven Development comes from Test Driven Development. In TDD, developers would normally write tests in a programming language. The tests would cover some areas of the application functionality. Because of that, these tests would only be understandable to the developers (or perhaps also to some technically minded QA engineers). However, non technical stakeholders, would not be able to read these tests.
BDD, unlike TDD, requires you to write test scenarios that describe the desired system behaviour in a human readable language. Such tests, however, cannot be executed and hence a second, corresponding set of tests needs to be written in a programming language. The second set of tests is called step definitions and these are the tests that get executed. Clearly, to practice BDD you need to write your the same tests twice!
This increases the time required for writing the tests and increases the cost of maintenance. Therefore, if you are only using BDD for automated testing and if your developers are the only people who look at the tests, then you are wasting your time and money. Perhaps a methodology that would not require you to write your tests in two versions, would be more appropriate and certainly cheaper. There is however a good reason for investing in BDD, provided you use it in a way that allows you to take advantage of all the following benefits:
Enhanced communication and collaboration
It should be well understood that Behaviour Driven Development is first and foremost a communication framework. The main point in practising BDD should be to allow not technical people who hold a stake in a software development project (project managers, business analysts, non-technical QAs, etc.) access and understand the tests. The tests are written in a human readable language and therefore they can be used to facilitate communication between technical and non-technical members of the team. BDD scenarios help establish a single version of truth.
Better visibility and ability to prioritise.
Like in Test Driven Development, BDD tests are supposed to drive the development. However, because they are written in a human readable language, they provide non-technical team stakeholders with better visibility of the software development process. It is easier for business stakeholders to assign business value to each of the tests scenarios and prioritise development this way.
Since BDD tests are written in a human readable language and since they define behaviours of the system, they can be used by both technical and non-technical stakeholders as a documentation of the software projects.
Last, but certainly not least, BDD scenarios can be used for testing the business logic.
As you can see, testing, as much as it is important, is only one of the benefits that BDD offers. The main idea behind BDD is to facilitate communication between all stakeholders.