Dear BDD Addicts,

In spite of the extra leap day, February went by very quickly for me. I had a few great days in Amsterdam at the last European Testing Conference (ETC).

Yes, it turned out (to me at least) that the concept of ETC was to try how modern testing conferences could look like and it was a time-boxed experiment for five years. It was strange because suddenly after the P3X conference last November, this was the second “last” conference I attended. (By the way, the good news of the month is that Skills Matter, the company behind P3X and many other confs are back in operation, so maybe in the end it was not the last P3X actually.) But back to ETC: the conference was designed in a way that the attendees had a plenty of opportunities to collaborate and discuss testing topics. I conducted a workshop on Example Mapping that also ended in interesting discussions. So now I am fully charged with conference ideas, just at the right time, because this year I joined HUSTEF conference as a program committee member where I can share them. HUSTEF is a 700+ attendees international testing conference in Budapest scheduled for November 2020 (the website will be updated soon). The call for papers is going to be opened very soon and I encourage you to submit a proposal and share your stories about testing, test automation and of course BDD.

But now… let’s jump to the monthly dose…

---

[SpecFlow] SpecFlow got acquired by Tricentis

The most of the questions or comments I have received recently were related to the acquisition of SpecFlow by Tricentis. I’ve got compliments, although I was not involved in this deal at all (it was between my former employer, TechTalk and Tricentis) and I’ve been asked questions related to the future of SpecFlow and generally about how an open-source project can be bought. I tried to collect my thoughts and answers for these questions.

Thoughts on the SpecFlow acquisition (Gaspar Nagy, @gasparnagy)

---

[BDD] Hey, listen! BDD IS NOT TEST AUTOMATION

In Twitter there arose some fuss about a discussion started by the old question: who is to blame if people abuse the BDD tools for test automation (and they get into trouble with that). Some people say that this “Cucumber’s fault” and should be closed, abandoned and disposed. This is especially funny, because Cucumber is an open-source project and it is impossible to dispose it, but this is a message that can awake some attention… a few bonus points for your social media profile.

This time though a new argument suggested that BDD, Cucumber or who even encourages people for the bad usage of Cucumber. This is not true, however. Me and my friends in the Cucumber community keep saying as loud as we can that BDD IS NOT TEST AUTOMATION; there is a better use of it. But instead of blaming those who use it in an improper way, we try to help and teach them about how to use it better. Please help us to spread the message! (And thanks for Aslak Hellesøy for the post.)

BDD is not test automation (Aslak Hellesøy, @aslak_hellesoy)

---

---

[BDD] Rules of good Gherkin

Since we compiled our six BRIEF principles of good BDD scenarios with Seb Rose, I have been watching the articles in this topic and I have been trying to match their suggestions to what we have collected. There is no single way of formulating thoughts.

The list by Andy Knight is something I especially like because it addresses the topic from a slightly different angle and it is spiced with a bit of humor.

Better behavior-driven development: 4 rules for writing good Gherkin (Andy Knight, @AutomationPanda)

---

[Agile Testing] Seeing agile through the water drops of the waterfall

I always ask the attendees at my courses if they have been working on a waterfall project. As you can expect, there are less and less people with such a background. But there are a plenty of us, still. Just like in the Agile Manifesto, testers are generally pretty much under-represented in agile-related articles and posts. So I am always interested if someone shares their experience from the testers’ perspective. Arnab Roy shares his thoughts in the following post.

What I Learned While Moving From Waterfall To Agile Testing (Arnab Roy, @logoutdany)

---

---

[Test Automation] The value of a test

There are things in software development that we just use without really understanding what they are actually. For me, tests were like that for many years. The eye opening event for me was a talk by Gojko Adzic at one of the NDC conferences many years ago, where he talked about quality and the problems defining quality. If defining quality is hard, it is probably even harder to define what a test is. Particularly whether a test that never fails is valuable or not. Is a safety net valuable if you never fall down? Probably it is. Are the training wheels valuable once you have learned how to ride a bike? Probably they are not. Paul Grizzaffi is digging into this topic with his post.

My Automation’s Not Finding Bugs, But That’s OK (Paul Grizzaffi, @pgrizzaffi)