Dear BDD Addicts,

Since the last issue of the newsletter, spring has finally arrived! We had a great tit couple nested in our garden making big noise with their 6 chicks. The weather is warmer now and there are also many people who started to write about BDD, test automation or agile testing, so it was not so easy to choose. If you have also seen a good post or article that has not been listed here, please let me know at bddaddict@specsolutions.eu, so that I can share with others.

Our birds left the nest today, so they “release cycle” has been done. How about yours? Did BDD help?

I hope that our monthly dose will inspire you further…

---

[BDD] Discover scenarios, don’t write scripts

I’ve had a BDD course recently, where someone asked me about the spread of BDD among the software projects. This is a usual question I get, so I showed them a few yearly reports presenting some figures (like the Hiptest report I’ve shared in the August issue of the newsletter). But the person replied: “Nice numbers indeed, but how much of them do a proper BDD?” This is a tough question, because it is hard to measure. But if you look at someone’s scenarios, as John Ferguson Smart says in his post, you can quickly see if they really practice BDD or just use it as a tool. A nail gun is not enough to build a house roof.

So you say you are doing BDD? The story of the whiteboard and the nail gun (John Ferguson Smart, @wakaleo)

---

[Process] WIP limit is not just a buzzword

When people learn about lean/Kanban agile processes, one of the first principle they encounter is limiting work-in-progress (WIP). There are many good illustrations about the benefits of WIP limits in manufacturing, where stocking things have a high cost, but when you try apply this principle to software, the benefits are not that clear anymore. Of course the cost of context-switching is clear, but what is wrong with working on 5 stories with a 5 people team? In her post, Janet Gregory focuses on this topic and she uses an illustration that can help us to better understand the bad implications of working on many stories in parallel.

Limiting Work in Progress (Janet Gregory, @janetgregoryca)

---

---

[Test Automation] Test automation solution: keep or let go

Manual regression testing does not scale, so we need automated tests to be able to deliver continuously. This way automated tests should help us keep our delivery speed and not slow down. Therefore they have to be reliable and maintainable. But what if they aren’t? Andrew Knight shared his thoughts on this.

Our test automation has problems. Should we start over? (Andrew Knight, @AutomationPanda)

---

[BDD] Did we forget about anything?

“Have we forgotten about anything?” this is probably the most weird question that you can often hear at requirement workshops. (Maybe in a form like “Is there anything else?” or “Did we discuss everything?”.) While the goal is to make sure if there are requirement gaps after our discussion, unfortunately these questions are very unlikely to help to remember things that we have forgotten about. (Since they are forgotten, aren’t they?) Have you forgotten where you put your keys? Trying to “remember” where you have put them does not help usually. Thinking over what you were doing and how you was moving when you arrived home is better. In the context of the story, it is easier to find the missing pieces. And the same works with BDD! Here are a few thoughts from me on this.

Example Mapping: 5 tips to avoid forgotten requirements (Gaspar Nagy, @gasparnagy)

---

---

[Testing/DevOps] What if you would have been the tester of 737Max?

Unfortunately from time to time there are serious catastrophes or incidents caused by the technological evolution. Sometimes they have significant economic impact only, like the battery issues of Samsung Galaxy Note 7, sometimes they affect human lives, like the crashes of the Boeing 737Max. As testers or generally as people working in software delivery, I think it is our responsibility to try to learn from the mistakes that led to these incidents, to be able to better avoid them in the future. But this is not easy. These issues are typically related to complex hard-to-test systems. “Integration issues” as we would say. But still, what if you would have been the tester of 737Max? The article by J. Paul Reed analyses the Boing crashes from this point of view. Interesting read.

The 737Max and Why Software Engineers Might Want to Pay Attention (J. Paul Reed, @jpaulreed)