Dear BDD Addicts,
November started with an unusually warm weather and brought a considerable increase of the virus spread that has been followed by stricter restrictions in most of the countries. At the HUSTEF conference where I was a track chair someone showed the Cynefin model, which classifies domains into chaotic, complex, complicated and obvious ones. And there is also a confusion area where we don’t even know where we are. So where are we now? Are we able to make well-prepared experiments and evaluate the results about COVID? This would be required to get to the complex phase.
Let’s hope. And let’s hope that the vaccines will be usable and we only need to deal with the logistics of vaccinating millions of people. That will be the complicated phase… And in a few years hopefully this becomes a routine and solving COVID becomes obvious.
But until that, let’s make use of the lockdown and see how we can make better software with BDD.
Here is your monthly dose…
[BDD] Don’t let your scenarios block the conversation!
I have stumbled across a post by Justin Rohrman about BDD from 2018 that I would like to share. He shares an honest report about the benefits and challenges of the BDD process they have introduced. I don’t remember how loud the BDD community was in 2018 about emphasizing that conversations are an important part of BDD, but Justin got to the same conclusion. Furthermore, he also realized that having a real conversation about the requirements is difficult if you also need to focus on the Gherkin syntax at the same time. By today Example Mapping and similar techniques have become more popular, but it is still interesting to read about the details of BDD being used in a concrete project.
BDD in Action: Dissecting the Conversation (Justin Rohrman, @JustinRohrman)
[BDD] BDD helps to better understand agile
We had already adopted many agile practices by the time I started using BDD. We had user stories, grooming meetings, automated tests and CI pipeline, but I understood the real benefits of some of these only when we started to use them as a part of our BDD process. BDD is not an isolated, stand-alone technique, but connects and includes many other agile techniques and principles. In this post I collected the 6 most important ones for me.
6 things that will make your adoption of BDD easier (Gaspar Nagy, @gasparnagy)
[BDD] Don’t miss the important aspects of the requirements
Our industry has been practicing writing “proper specification” for decades now. Still, we are not really good at it. Or at least I haven’t found any that proved to be perfect. Often the problem is that the ones writing the specs see the problem only from a certain point of view and therefore they miss some aspects that are in the shade of their initial thought. Examples enable the team to collaborate on the requirement and significantly reduce the amount of forgotten details. A post by Seb Rose.
Better requirements by harnessing the power of examples (Seb Rose, @sebrose)
[Process] Do reviews right!
Many teams work remote nowadays. Giving feedback about each-other’s work is harder and by using more formal channels like email or GitHub there is a bigger chance that the feedback becomes or received as personal. Some folks at Google created a quick summary of useful review techniques. It even comes with a printer-friendly version to display in your office wherever you work from nowadays.
Code Health: Respectful Reviews == Useful Reviews (Liz Kammer, Maggie Hodges, Ambar Murillo from @googletesting)
[Automation] Testing async services with Cucumber
I have chosen the article by Moisés Macero as the last one for this month; he is the author of the Apress book Learn Microservices with Spring Boot. This article is actually the fourth part of a series but can also be read without reading the others. The article focuses on how to test asynchronous services and eventual consistency, but it is also a good showcase of how the actor model can be used with Cucumber.