Dear BDD Addicts,

The year is close to finish… people have started to make their conclusions for the year. But it’s hard to tell how much these are going to be valid for the next year or the years after. In spite of the changes that have impacted all of us, I have learned a lot about BDD this year. I have seen how collaboration can find its own ways even in constrained situations. I have seen such discussions; learning about BDD works well remotely. I have learned how beneficial it can be in tough times if you have a consistent continuous quality strategy for your software projects.

This is the 50^th issue of the BDD Addict newsletter, where – like always – I’ve tried to collect interesting BDD, test automation and agile testing related articles. So we have a reason to have a little celebration here.  

 Thank you for being a part of it. Next year we will move on, so if you see any interesting article, please share it with me at bddaddict@specsolutions.eu. And now I wish you a merry Christmas and really happy holidays.

So here is the dose for December…

---

[BDD] How can formulation help to discover important (but missed) business details?

I have mentioned already about the #GivenWhenThenWithStyle discussions coordinated by Gojko Adzic. They are different Gherkin formulation-related challenges where readers can submit suggestions that Gojko evaluates and shares afterwards. There are discussions about concrete day-to-day problems so definitely worth checking them out. This time the topic was an innocent-looking problem: how should we include dates in the Gherkin scenarios, and the example was a payment cancellation date calculation. The discussion also continued on twitter and finally, we have got three articles written: the original solution by Gojko; an article by Seb Rose who suggested to decompose the problems; and an article by Daniel Terhorst-North who dug even further into the original business problem and came up with the idea that with a different calculation rule the entire problem would be simpler. Read them! They are interesting not only because of the dates, but also because they are a great example of how formulation can help to discover important (but missed) business details.

Solving: “How to specify relative periods?” #GivenWhenThenWithStyle, Seb’s response, Daniel’s response (Gojko Adzic, @gojkoadzic; Seb Rose, @sebrose, Daniel Terhorst-North, @tastapod)

---

[Agile] Different ways of probing

Agile is about listening to feedback and when we apply this to complex software problems, in many cases we use different kinds of probing to get feedback. We try out things and see how they work. There are different kinds of probes though and miscommunication about their goal might undermine their value. Liz Keogh gives a good summary about the different probe kinds we use and about the phenomenon where we accidentally communicate the probe as a commitment.

A Probe by Any Other Name (Liz Keogh, @lunivore)

---

---

[Agile Testing] Specifying or validating a problem where the outcome is hard to express? Approval Testing might help!

As being a BDD addict like me, you might also tend to think that Given-When-Then is the only way to capture and verify business expectations. Obviously this is not true. Although Given-When-Then is good for many typical business problems, sometimes it makes sense having a look around what other options are available. One particular idea that is worth having a look into is Approval Testing. You might have heard about that in the context of UI testing, but approval testing is a method that can be used for any kind of problems and it particularly excels for cases with complex outcome. Emily Bache gives us a summary of this and also some ideas on how this is related to BDD.

How Approval Testing can support Behavior Driven Development (Emily Bache, @emilybache)

---

[BDD] Focus your “getting started” energy on the outcome, not on the tools

Many teams started to use BDD and there are also many teams who could not get the most of the benefits out of it. There are now many articles emphasizing that you have to focus on the process and do not take BDD as a testing tool only, however, the article by J. B. Rainsberger is a bit different. It raises usual adoption anti-patterns in a very natural way, so that we can better understand how we might get trapped. And how we can avoid them so that the success of BDD does not become an “illusion [that] falls apart” quickly.

BDD: Before You Begin  Part 2 (J. B. Rainsberger, @jbrains)

---

---

[Agile Testing] More bravery in 2021

I am often asked questions from testers about how they can improve their carrier, how they can be more respected members of their teams. My answer is regularly that you need to keep learning and stand up for yourself. They often misunderstand the learning part that they have to train themselves for another job role like a developer. While this is definitely a possible option, I have not meant learning that way. To be able to stand up for yourself, you have to be confident in your own field. Learning does not necessarily mean that you have to do a training or practice a new technique. In many cases being aware of what possibilities and options are out there is a big step ahead. Lisa Crispin shares some of her thoughts about how we could develop ourselves as testers. I think this makes a good end of 2020… See you next year!

Needed more than ever: courage (Lisa Crispin, @lisacrispin)