Dear BDD Addicts,

This October was a busy month. Conferences, courses, on-site coaching. But whenever I was thinking about how I should introduce this newsletter, I always ended up thinking about Skills Matter.

Last week I was in London at the P3X conference at Skills Matter. Friday was the last day of the conference, and it turned out that possibly it was the last day of Skills Matter as well. Skills Matter has gone in administration (appointed administrators trying to sell the business or closing it if that fails). P3X is my “home conference” if there exists such a term at all. It has been organized since 2009 (it was called BDDX before 2017) and I have attended many of them and have been part of the program committee for a couple of years now. This was the conference where I’ve done the majority of my knowledge exchange around BDD in the last 10 years and here I’ve met a lot of people who have been influencing my activity. Skills Matter has been playing a key role in establishing a community committed to build quality software and their company has also served as a role model for other local communities and meetups all around Europe and beyond. So please let me dedicate this issue of the BDD Addict Newsletter for everyone who worked and contributed to Skills Matter.

This is not the end.

So let’s keep working.

---

[Agile] Fail, learn and move on

On the occasion of the 50th anniversary of the Moon landing, I have been reading about the Apollo 11 project and have found a couple of interesting details that might carry a message for agile software development as well. One of these small details was that before the launch the crew (Aldrin, Armstrong and Collins) were told that if they failed to land on the Moon they could lead the next mission as well. (Normally the assignment of the  people to the missions was rotation-based.) With this, NASA wanted to avoid that the crew took unnecessary risk during the project. There is always a new chance, so we should better fail and learn from the failures. This is what Tim Ottinger’s thoughts are about.

This is NOT the End (Tim Ottinger, @tottinge)

---

[BDD] What BDD practices are useful?

Agile is about inspecting and adapting and this is also true for the agile practices, like BDD as well. Something that I have found useful, might not be relevant for you, but another thing that I was not focusing on might have more impact. This is why I like attending conferences and exchange BDD experience. And also this is where questionnaires and statistics are also helpful. They show how people adopt things. Matt Wynne and the SmartBear team have recently made a quick survey. Matt has summarized the results in the following post.

What do high-performing BDD teams do? (Matt Wynne, @mattwynne)

---

---

[BDD] Drive your requirement workshop

There is one thing in common in all the companies I visit nowadays. They have all realized that they could improve their development process further only if they reduce the waste (time, code, etc.) caused by the suboptimal communication of requirements. I show them example mapping (and other deliberate discovery practices), we also practice it, and it becomes quickly visible that these practices can really help. However, collaboration, which is the essential part of them, does not come automatically unfortunately. Unfacilitated meetings quickly turn into an “Is it clear? – Yes” kind of discussions. Becoming a facilitator of such meetings needs a bit of practice but it is not super hard. I have tried to collect the most important facilitation techniques I use.

Example Mapping: the good enough facilitator (Gaspar Nagy, @gasparnagy)

---

[TDD] Properties of automated tests to consider

I have labeled this post with “TDD” but it is more about test automation in general. I have seen that people like categorizing and establishing rules too rigidly, while the test automation landscape is much more diverse. There are different contexts and we need to find our way there. I prefer the concept of listing principles or properties that can or should be considered. You are not obliged to keep them, but you should have a good reason not to do so. Kent Beck has made up a quick list of such properties with a few examples on how to use them.

Test Desiderata (Kent Beck, @KentBeck)

---

---

[Test Automation] Clean, but not so dry

A proper implementation of the agile principles on a project requires us to think differently about testing and test automation code. Quality (and all related testing and coding activities) are the responsibility of the whole team. The results should be treated as important and valuable artifacts. “Tests should be treated as first-class citizens” is a commonly expressed attitude, and it follows that test automation code should adhere to local coding standards, such as the “Clean code” principles. There are discussions about how these principles can and should be applied to test code, especially on the “Don’t repeat yourself” (DRY) principle. While the DRY principle for production code is important to avoid duplication and redundancy, for test code, keeping the structure simple and readable (sometimes mentioned as DAMP — Descriptive And Meaningful Phrases) seems to be more important than the DRY principle. Luke Morton shows a couple of concrete examples for this problem.

When to avoid the DRY principle (Luke Morton, @LukeMorton)

---