“I’m the smartest man in Athens because I know that I know nothing.” —Socrates 470-399 BC
What BDD is (for me)
1. Conversations
BDD is about conversations
The conversations help us understand what we are trying to build and identify the behaviours of our application
The conversations help us share the knowledge about what we are building
Through the conversations we deliberately discover the behaviour of what we are building and remove some of our first order ignorance
BDD uses continuous feedback for deliberate discovery
The discovery helps reduce the unknowns and deliver software that matters
2. Documenting the behaviour of an application
BDD scenarios (or tests) help document the behaviour of the application we are building as they document the outcome of the conversations
3. The tools
There are a number of tools that allow automating the execution of the scenarios.
4. Testing
BDD tests assumptions through conversations, no other relationship exists.
My conclusion
“BDD is about conversations and collaboration to generate software that matters”
that means:
the conversations generate the software that matters
and
“Wherever it makes sense, describing the the behaviours in business language through scenarios and automating them will help you produce fast feedback and maintain the application as it grows.”
that means:
using scenarios and good engineering practices you can be more effective
If you don’t do point 1 (the conversations) you can produce as many scenarios as you want, automate and run them continuously in a server farm bigger than Google’s but you are not getting much value and in my humble opinion you are not doing BDD.
Liz Kheogh, whose contribution have strongly influenced the evolution of BDD puts it very simply saying:
What BDD is NOT (for me)
A recurring problem I have encountered with teams starting to use BDD is the emergence of fallacies where teams conflate the problem that BDD is trying to resolve with other concerns, in particular, tools, artefacts and testing.
I am going to come clean straight away, I have been culpable of this for a good while and learned on my own skin how mixing up concepts can be extremely dangerous. See some of my lessons learned below.
#Fallacy #1: BDD is Testing and automation
This is a very common problem. Often it originates when somebody (usually a tester) hears or reads something about BDD and starts using Gherkin and BDD scenario style to write their tests. This has usually a honeymoon period in which benefits are reaped because tests are now written in business language hence readable/understandable by everybody. This seems to help communication, but in the long term it actually makes it worse because testers and developers start communicating through scenarios written in Gherkin and stop talking. I have personally done this many many years ago. Hands up I screwed up my team communication badly!
In some cases a decision is made to use BDD scenarios to replace automation tests. This creates a confusion around what scenario should be written for developing some behaviour (BDD) and what scenarios should be written for testing the application. Using all boundary, invalid, special scenarios for development is not optimal, we are not looking for bugs, we are building an application based on its behaviours.
Very often, testers will push for having the scenarios automated through the UI and run in an end to end full integration environment. This generally creates a large slow and non predictable automation suite that is not suited neither for BDD fast feedback loops and discovery nor for end to end integration tests.
When conflating BDD with testing we create unnecessary confusion and end up with things that are neither regression tests nor BDD scenarios and are unusable for their original purpose (development of software that matters).
Do you want to avoid all these problems? Separate BDD from testing. They are 2 solutions to 2 completely different problems. Use the appropriate tools for each domain. Live happy.
#Fallacy #2: BDD scenarios are a communication tool
In some shops I have seen business analysts and product owners that had heard or read of BDD decide that they were going to formalise the requirements into BDD scenarios. I have seen this approach, suggested by a few people that do BDD training, but it is a recipe for disaster. The most important part of BDD is completely ignored and the PO will elegantly formalise his assumptions in BDD scenarios. Once a developer gets the BDD scenario, she will deliver the PO’s assumptions into elegant code.
Tests for their nature cannot be ambiguous, there is no need for questions or conversations if requirements are defined in the form of tests. This is brandished as a great advantage by some people, instead it is the death of deliberate discovery, and the birth of Assumption Driven Development(*).
Do you want to avoid this? Use 3 Amigos conversations as communication tool. After you’re done, you have all the information to formalise the findings of the conversations into BDD scenarios
#Fallacy #3: We use Cucumber we are doing BDD
(Feel free to replace Cucumber with Jbehave, SpecFlow, et cetera)
This is a non sequitur.
Some developers get very excited by neat tools and the ones I mention above are quite cool. Using a tool and writing software through BDD scenarios in the absence of conversations is different from doing BDD. Again, in the absence of conversations, inevitably we end up doing Assumption Driven Development(*).
A similar non sequitur fallacy: “We use Jira, we are agile!”.
I am looking forward to the day in which I will feel ashamed of what I wrote above, because that day I will have learned something.
(*) Assumption Driven Development (ADD) = A person single handedly builds a set of unquestionable assumptions about the behaviour of an application in the form of tests. Normally this approach fails late, when at exploratory testing, somebody questions the PO’s assumptions now built into code.
| Reference: | BDD is – BDD is not from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
