BDD Without the Three Amigos: Maybe Talking To Yourself Isn’t So Bad
If you search online for articles on Behavior-Driven Development (BDD), you’re likely to find more literature on how everyone is doing it wrong versus what it really is and practical success stories in using it. I’ve read article after article explaining how teams are claiming to practice BDD but are falling short on the core intention of this process which is to communicate early in the development process to ensure the team is building the right thing.
BDD is ideally practiced by what is known as the three amigos: the business, the developer, and the tester. However, in the real world, it’s quite the uphill battle to get team buy-in to actually practice BDD in its pure form. Excuses I often hear from the business people are that they don’t have time to learn something new. Developers say they don’t want yet another meeting and don’t see why this is necessary. Which leaves the tester as the only willing participant.
So, without the three amigos, BDD purists argue there is no BDD! Yet, more and more testers are giving up on trying to get everyone on board and are focusing on one of the shining side effects of BDD: executable test scenarios! When I consult with teams who are simply using Gherkin for test automation purposes, I regurgitate what I’ve read in the literature:
- this is not proper use of BDD; communication is key
- you’re not getting the full advantages of pure BDD
- you’re adding an unnecessary layer of code to your automation framework
Shockingly, this has never been news to any of them. They are all well aware of the intentions of BDD and how it should be used. However, obtaining team buy-in was a battle lost, and they really, really want the executable test scenarios which can be written by their non-technical testers and plugged into a framework developed by automation engineers or developers. In addition to having more people contribute to the automation efforts, they also value the scenarios serving as documentation of how the system behaves.
I’ve seen multiple teams operate this way and they are very satisfied with what they have. I’ve waited for the bottom to fall out of their automation strategy, but it hasn’t. I’m not exactly sure if I’ve just not waited long enough, or if maybe using BDD testing frameworks (e.g. Cucumber, JBehave, Specflow, etc) for the sole purpose of test automation is not as horrible as the purists have made us believe.
This caused me to stop and think…why is everyone preaching against operating this way? In theory, it makes total sense. Heck, I’ve preached against it myself. However, I couldn’t find an answer to the why in any of the articles or in my own thoughts other than this is not how BDD was intended to be used and therefore is not BDD. But we all know that users don’t care about the intended use of software or processes; they use it to meet their needs. Maybe this is no different?
In discussing this topic on Twitter, I realized that I have never seen a tester successfully gain team adoption of BDD. The teams that I have seen doing BDD have all had the process pitched by a non-tester. So maybe instead of yet another “you’re not really doing BDD” article that assumes automation engineers are naively using these testing frameworks, we should put more focus on how to get team-level adoption to practice BDD in its pure form and obtain all of the wonderful benefits that the testers and automation engineers are fully aware they are missing out on.