Dear BDD Addicts,

The beginning of the year is usually a bit more quiet for me as typically fewer courses take place. So this is the time to make those changes that I don’t have the time for during the in-year rush. Last year I used this time to create an ordering and payment system for my company and this year I decided to document the development process of our product SpecSync.

Thinking over and even putting down things that you do day-after-day anyway is an interesting experiment. At first sight it seems to be senseless, but actually it helps seeing some connections that you haven’t recognized so far. I do this from time to time with my BDD scenarios as well: open them as if I saw them for the first time and see if they still make sense as a whole. You will surely find some things to improve!

Are you ready for some inspiration? Here is your dose…

---

[BDD/Video] Programming by remote control using BDD scenarios? No!

Dave Farley’s YouTube channel always provides useful content. Not only about BDD, but also about software development in general. He has recently posted a video about the usual problems teams fall into when using BDD. Totally matching to my experience, the click-here-click-there kind of scenarios are also the Nr 1 on his list, but he mentions lots of other interesting things, too. My favorite is what he calls “Attempt programming by remote control”. I have seen this situation so many times when the top architects or the business is trying to describe in a very low level detail what to do, degrading the team to a coding machine. And this is sometimes done through BDD scenarios! This is not a good way of working for sure. Why? Check out the new video by Dave Farley and you will learn.

When Behaviour Driven Development Goes WRONG! (Dave Farley, @davefarley77)

---

[Agile Testing] Learn what quality means to you!

One of my favorite topic is software quality. It’s just a simple term that we use quite often, but if you needed to define what it really means or rather what it really means to your team, then you realize that it is pretty hard to do. For a long time I have been using the quality aspect model I made based on Kevlin Henney’s concept. This uses the functional, operational (e.g. performance or usability) and strategic aspects (e.g. code quality or design). But even for these aspects it is difficult to find the criteria that are really important for you.

Experiments are very important to perceive how we can achieve improvements on a particular quality aspect and how to better assess its importance in the end.

I missed the Agile Testing Days in 2021 so I was so happy to read the summaries by Lisa Crispin. In the linked post, Lisa provides a summary of Elisabeth Hocke’s talk on experiment-driven quality approach.

Experiment-driven quality (Lisa Crispin, @lisacrispin; Elisabeth Hocke, @lisihocke)

---

---

---

[BDD] Are feature toggles compatible with BDD?

BDD describes the functional quality expectations of the application we build. Functionality is a static requirement most of the times. Either you want to have that particular behavior or you don’t. But with many modern system, especially the SaaS-like products, the features are introduced dynamically: they are behind a feature toggle that can be enabled or disabled dynamically depending on the needs. Maybe it is only enabled for a smaller set of users first or it can be completely disabled if you find a problem in it.

Describing the expectations of such a system with BDD scenarios is somewhat tricky, because you need to describe the behavior depending on the current setting of the toggles. In his article, Trevor Stuart provides a case study of how they have solved this problem with scenario tags. They have even created a small open-source Cucumber plugin that can be used to implement similar solutions.

Bringing feature context to your testing best practices (Trevor Stuart, linkedin:trevorbstuart)

---

[Agile] Is transparency always good?

I read the Todd Lankford’s article somewhen last summer and saved the link. It has come to my mind a few times since then, so I think it is definitely worth sharing it even if it is not about BDD directly.

This is one of those articles that attempt to break the illusions many of us have about “agile” projects. In this case about the transparency. I think we all agree that transparency is a good thing and I’m sure we have several reasons to say that, but seeing something being useful in a few situations is not the same as generally declaring something to be good. I really liked this article, I hope you will enjoy it, too.

How transparency can kill productivity in Agile teams (Todd Lankford, @ktlankford)

---

---

[Test Automation] Keeping trust in our automated tests

The flakiness of automated tests is one of the top reasons that undermines the efforts and enthusiasm we have invested into test automation. These problems are typically very difficult to handle, especially if they are combined with a less structured automation codebase and if it affects a broader range of tests.

There are no fixed recipes in the article by Nebojša Stričević, but it highlights the systematic care that can help you to get out of such a situation.

How to Find and Eliminate Flaky Tests (Nebojša Stričević, linkedin:nebojsastricevic)