The single most important of Behaviour-Driven Development (BDD) is the conversation, not the tooling, Liz Koegh states in a presentation about 10 years of doing BDD at a recent Cucumber conference.
Liz, an independent agile coach and contributor to e.g. JBehave, believes we have made some big mistakes during the years of practicing BDD, but she is quite excited about our current understanding and some of the developments that has happened over the last few years.
Dan North in 2003 first came up with the idea of BDD by defining it as a bit like TDD but using the word "should" instead of "test" to describe how a system should behave. BDD was then formally introduced 2006 by Dan after finding that talking about behaviour, particularly about examples, was more useful than talking about tests.
One mistake Liz made during the early years was trying to replace the word "should" with "must" or "will" to get closer to a contract and a lot of people agreed, but Dan emphasized that should is preferred since it encourages questioning and conversations.
Another mistake increasingly made by the community using BDD was people claiming to do BDD but without any conversations and talking about BDD tests when the purpose was to move away from the word test, instead asking stakeholders and domain experts about examples on behaviour or scenarios.
Liz emphasizes the need for people to go back to the conversations. She has found that the focus on test automation actually slows people down by writing too many scenarios and focusing more on tooling than on conversations, the message being to step away from the tools, BDD will not work unless you have the conversations to explore the behaviour of a system.
A new concept Liz finds very interesting is Cynefin as a way of estimating complexity, focusing on scenarios with a lot of uncertainty for the business and using BDD in these areas to spot the outcomes.
Liz ends her presentation with the main purpose of BDD:
BDD is about writing software that matters (using examples!)