The monthly dose for BDD addicts… In October #bdd, #specflow and #cucumber stories by James Jeffery, Angie Jones, David Leitner, Chris Matts and Simon Powers..
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the September issue?)
Dear BDD Addicts,
I’m just flying home from the Agile in the City Bristol 2017 conference, which was really good. Good sessions, friendly atmosphere, good conversations with old and new friends. As a last minute idea, I also subscribed myself to a lightning talk in addition to my regular one. I had to work quite much for that 10 minutes, but I had an idea of a talk for a long time that I wanted to give a try to. I usually take notes of every story that I hear which works well as a metaphor of a software testing challenge. These are not IT-related stories, but still, I like them because they help me to see these challenges from another perspective. I have around 10 such stories by now and I have selected three of them to fit for the 10 minutes. But I hope I’ll able to extend it to a full talk once. If you have a good story that would fit, please let me know.
But now… let’s get our monthly dose…
[Case Study] Impact of BDD in numbers
Many BDD practitioners observed the reduction of production or pre-production issues after introducing (proper) BDD practices to their projects. Having less issues is a really important achievement, because it can have a direct impact of the user satisfaction, especially if we talk about production issues. Simon Powers summarizes the benefits of introducing BDD to a banking project with a different measure though: the amount of time spent for bug fixing. (We are talking about the fixes of the bugs of the stories that have been already “done”, not the in-sprint corrections.) Maybe not many teams have such a measure yet, but it is relative easy to establish it and it makes the reduction of bugs much easier convertible to cost savings. Really interesting report!
A case study for BDD in improving throughput and collaboration(Simon Powers, @agileadventures)
[Process] Then-When-Given
It is not much well known, but Chris Matts was the person who suggested to use the Given/When/Then keywords that we all use nowadays for BDD scenarios. Given, When, and Then might be seen as just three labels that make scenarios more readable, but the reality is that they refer to very different aspects of the specification. The Given steps set the context or pre-condition, the When steps describe the function that we are about to specify and the Then steps describe the expected outcome or post-condition. In his post, Chris talks about the role of these steps in detail including how you can avoid irrelevant pre-conditions by thinking about the steps in the reverse order.
Three top tips for using Given When Then (Chris Matts, @PapaChrisMatts)
BDD with SpecFlow Course in London
Eager to learn about SpecFlow and BDD?
Join my SpecFlow course in London to learn how to apply BDD for .NET apps.
The course is for developers and testers, who are involved in automating BDD scenarios. As the course exercises are based on pair-programming, product owners or business analysts with basic coding knowledge are also welcome.
See the detailed course outline and book your seat on the event page.
BDD with SpecFlow
[Test Automation] Excuse me for testing your app
I used non-IT stories to talk about testing challenges. James Jeffery addresses the topic with humor. I cannot even add much to that… have fun!
Common Excuses Why Developers Don’t Test Their Software (James Jeffery, @JamesJefferyUK)
[Test Automation] The Refactoring Tunnel
Staying with the metaphors, this one is also interesting. It is about refactoring, which seems to be a more complex topic than it seems. Think about refactoring stories, refactoring sprints or even never-ending refactoring that has to be rolled back finally. These are all symptoms of the confusion about refactoring. Matt Wynne compares refactoring with cleaning up the desk after finishing a dish in a restaurant. When we worked on our book with Seb Rose, we came to the conclusion that refactoring should be rather called review, which might or might not lead to some concrete actions. Anyway. David Leitner is here with the refactoring tunnel. Let’s enter.
The Refactoring Tunnel (David Leitner, @duffleit)
The BDD Books: Discovery
Explore behaviour using examples
This book is written for everyone involved in the specification and delivery of software (including product owners, business analysts, developers and testers). The book starts by explaining the reasons that BDD exists in the first place and describes techniques for getting the most out of collaboration between technical and non-technical team members.
It’s also worth stressing that this book is tool agnostic. Whether you use Cucumber, SpecFlow, JBehave, Fit, FITNESSE, RSpec, Jasmine, Behave, or any other BDD tool — this book will help your team collaborate.
Available on Leanpub: http://bddbooks.com/discovery
[Test Automation] Multi-level tests
No, this is not about multi-level marketing… this is about tests that cross the levels of the test automation pyramid within a single test! This is Angie Jones, with her clear and straightforward, but still pragmatic post!
Hybrid tests: Blurring the lines of the automation pyramid (Angie Jones, @techgirl1908)
