When I presented BDD with UI Automation at STPCon Fall’17, Washington DC, one of the audience asked for thoughts on how they should use Behavior Driven Development (BDD). Because we were running out of the assigned time slot for the presentation, I didn’t get a chance to describe my views. So, I thought of writing it down instead.
My thoughts about BDD is pretty simple. As long as you are creating a shared understanding of how the product should behave and create an executable & living documentation on-the-go — you’re doing BDD.
But, the real question was of more like,
how do we do it? It’s as simple as 3 steps,
1. Discuss the Behavior: have 3-Amigos to discover the unknowns
2. Document the Behavior: elaborate the discussions in plain-text Gherkin language with concrete examples, e.g. the .feature files — the living documents
3. Execute the Behavior: run the a_utomation & get early feedback_
1. Discuss the Behavior
“The team goes wrong when they start assuming the expected behavior to build the system.”
It’s about to discuss the behavior of a feature and flush out all the acceptance criteria and edge cases.
BDD is a highly collaborative process where discussion happens to derive the expected behavior with concrete examples. One of the ideas of BDD is not to assume that one person has all the answers, and that’s the idea behind 3 Amigos, usually 30 mins of conversations, and it requires three different disciplines to have that conversations to discover unknowns at an early stage.
Three disciplines from Business, Solution, and Problem have these conversations, where Product Owner represents the “Business” space, Developers represent the “Solution” and “Test Engineer” represents the “Problem” area.
Business creates an EPIC. EPIC then breaks down to features, and features to user stories; let’s call it Feature Breaking. 3 Amigos happen at the second stage; Feature Breaking, where three disciplines have the thoughtful conversations about,
How a feature should behave?
Can you give us more examples?
Are there any edge cases?
All these conversations recorded as Bullet Points. The most important outcome of 3-Amigos is, the Edge cases scenarios are identified in an early phase, unlike in Waterfall. It gives the developers a first chance to take a pause, thought about scenarios before coding and prevent bugs rather than fixing at a later stage.
2. Document the Behavior
Once the team has the conversations about the feature behavior as 3-amigos, now it’s time to explain the conversations with concrete examples. It’s the process of documenting conversations in Plain Text English like Gherkin syntax — Given When Then (GWT).
Often called, Feature files in Cucumber.
Eventually, the feature files become the essential part of the Product Specifications. These specifications are developed & automated using tools such as Cucumber. These specifications are Living Documentation. Since it also become part of regression suite, they never expire.
These are Living & Executable Documentations.
Usually, in Agile, we don’t work based on documents like in Waterfall, but we expect to create documents as we progress. The tools like Cucumber helps to create such Product Specifications, the .feature files, which are shareable, executable and living.
3. Execute the Behavior
Now we have documents defined, and team knows exactly what to develop, what to test and what to automate — this stage is to develop the feature.
The plain-text-english document will be implemented and automated with tools like Cucumber.
Once development & automation is done, the team executes those plain-text-english documents as part of acceptance-tests suite. If the document comes out GREEN, Accept the Story.
The Documents (feature files) become essential part of the Product as they are executable, living and most importantly — they reflect the product behavior.