When I presented with UI Automation at 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. BDD STPCon Fall’17 , 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, It’s as simple as 3 steps, how do we do it? have 1. Discuss the Behavior: 3-Amigos to discover the unknowns elaborate the discussions in plain-text Gherkin language with concrete examples, e.g. the . 2. Document the Behavior: feature files — the living documents run the a_utomation & get early feedback_ 3. Execute the Behavior: 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 at an early stage. discover unknowns 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 syntax — . Gherkin Given When Then (GWT) Often called, Feature files in . Cucumber Eventually, the feature files become the essential part of the These specifications are developed & automated using tools such as Cucumber. These specifications are Living Documentation. Since it also become part of regression suite, they Product Specifications. 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 document will be implemented and automated with tools like . plain-text-english 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 , Accept the Story. GREEN The Documents (feature files) become essential part of the Product as they are executable, living and most importantly — they reflect the product behavior.
