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 :).