Yes, I deliberately led you here with the fact that BDD is “Buzzword Driven Development”. Hey, Panda said it first ;).
Seriously, though, Behavior Driven Development has been an interesting experiment. I’ve worked with it and I’ve worked against it (not trying to tear it down, meaning I’ve struggled to work with it effectively and feeling like it was against me).
BDD is not magic! Let’s get that out of the way first. BDD requires development chops. BDD requires curation. BDD requires that all of the people involved are on the same page. It sounds so simple and yet, in practice, many teams struggle with it. Is there a way for us to do better? I think there is. Oh yeah, Andrew does, too ;).
First off, does your organization have a Three Amigos option? If not, consider it. If so, are you as a tester part of that Three Amigos arrangement? Not necessarily all of the time but definitely some of the time? If so, great, that’s good to know. If not… ok, mission one is to get into that rotation.
Next, do we actually understand the process and procedures necessary to get business language to become an actionable code? I’m not saying everyone needs to know how to code but scenario mapping should be something that everyone, at last, understands what goes into making sure that the scenarios actually do something and that the “actually do something” process is well understood.
Again, I want to make sure to state that business language like Gherkin is not at all magical. It’s is just documentation. To make it become automated tests requires mapping each statement to underlying code functionality. That code functionality needs to be clear as to how it behaves and responds when it is called. Use examples. Have the examples be as clear and concise as possible. Also, take the time to be specific and focus on direct language where you can. I enjoy using the features in Gherkhin and they are fairly easy to implement. Can they be sued? They sure can. Can they be confusing? They sure can. Remember, just because you can do something doesn’t mean you should. Use tables and scenario outlines when it makes sense to. USe variables where it makes sense to. If possible, word things to that there is a minimum of variables and other structures visible in your examples (that’s a personal opinion, by the way).
One of the nice benefits of taking the time to write Gherkin and to create the scenario mappings is that, in time, future tests and requirements will take less and less time to write scenario mapping and more use of Gherkin statements that “just work”. wait, didn’t I say that doesn’t happen? I did, but over time, once we have identified as many behaviors as possible, ultimately we will be reusing what already exists, and that’s pretty neat :).