My name is Anthony and I am a Test Manager. In November 2016 I attended a BDD (Behavior Driven Development) workshop in Sydney because I wanted to get a fresh perspective on how testing can work within an agile project. On the surface, BDD seemed like the answer to a recurring problem that I have witnessed on projects, how do you avoid sprints becoming mini waterfalls i.e. where manual testing is repeatedly back-ended to the last few days of the sprint which may impact quality? I wanted to know more about BDD and ideally, leave with a good understanding and a few ideas.
BDD kickstart was a two-day session hosted in Sydney by MagenTys (Hamish Tedeschi and Tim Myerscough) and Cucumber Ltd (Steve Tooke). The class was well attended with a good mix of Testers, Developers and Business Analysts (shout out to my learning buddy (Laura V) who had flown in from North Carolina to attend).
On the first morning, we focused on what we each wanted to get from the course. Following this, we looked at definitions, introduced the power of examples and explored our understanding of Test Driven Development (TDD). After lunch we looked at examples, why example concreteness (is that a word?) matters so much, and then we jumped straight into to exercises that reinforced the morning’s learning and got us hands on with Gherkin. We also learnt about a time boxed elaboration/collaboration technique called Example Mapping, a great takeaway.
By the end of the day we had all interacted in groups, sketched on numerous pieces of butcher paper (that were now plastered over the walls), traversed the room many times during interactive exercises, discussed, laughed, shared, and personally, I learnt a lot. The day finished with a few beers and war stories with some fellow BDD enthusiasts.
Day two we were straight into example code (Java or C# – we had a choice). We played around in an IDE looking at feature files, step definitions and explored how it all fits together. We worked through some exercises writing failing tests, debugging code, passing tests and adding more scenarios. This was my lightbulb moment, actually seeing BDD in action brought it all together for me. I admit I spend far less time in code than I would like but the exercises were clear and well documented. Tim, Steve and Hamish were also on hand to offer expert coaching when required. By the conclusion of day two, I had a clear understanding of the fundamentals of BDD, had areas to explore further, resources to help guide me in my exploration and techniques that I could use right away in the real world.
Since completing the course I have introduced example mapping concepts successfully and have been championing the idea that examples concreteness (that word again) is king. I have also produced a sketch note of what I learnt on the course (comments/feedback on this most welcome). Now that I understand the concept of BDD I have changed my opinion slightly, I think that automation could be a very useful side benefit of BDD (if you take it that far), but it’s how you go about the elaboration, exploration and the discovery of User Stories that’s where the real and most immediate value lies. This is where I have started… my journey continues.
Marketing Executive at MagenTys