Dear All,

First of all, I wish you a very happy new year for 2021! Are you busy? For me, the first few weeks have not been very intense. Usually there are not many trainings in the first months and I really have to force myself to progress on other duties I have. Especially since we’ve just got the first snow this winter… Who wants to work when this happens? (In Hungary there are usually only a few weeks of snow only, and it is getting less and less.) But the newsletter (and YOU, dear reader) is an exception.

I am eager to present this to you, especially because similarly to the previous years, this is a “BEST OF” edition where I analyzed the statistics of all 31 articles I shared in 2020 and selected those that were the most interesting for you. I focused on the article-like posts and skipped some high scored announcements, like Gojko Adzic’s Given-When-Then With Style initiative or my thoughts on the SpecFlow acquisition. So here are the top 5 articles that got the most interest in 2020. This way I would like to say thank you for all the authors who contributed to the newsletter last year and to all of you, who took the time to read about what happened around us in BDD, agile testing and test automation.

See you in 2021!

---

[Test Automation] How to make the testing pyramid more useful by making it less restrictive

We have been talking about the test automation pyramid with Seb Rose countless times. Not because we disagree but because it is hard to find the right words and the right approach to make a better use of it. Because team have problems with the pyramid for sure. But is it the shape, the lack of the third dimension or the labels that cause trouble? In his post Seb shows how an eviscerated pyramid looks like.

Eviscerating the Test Automation Pyramid (Seb Rose, @sebrose)

---

[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)

---

---

[BDD] Definition of Done brings focus

I can still remember my Scrum training: Definition of Done (DoD) was discussed right on the first day. It sounded clear: we need a checklist to make sure we haven’t forgotten anything. But when we started to apply it in practice, DoD quickly became a list in a template that we copy-pasted to every project without too much care. We never looked at the DoD during the Sprint because it contained only the boring known stuff, like don’t forget to check-in your code and update the documentation.

But Definition of Done is more than that! It is a part of the contract between the team and the product owner. But the contract only makes sense if both sides are able to understand it! And this way we have already arrived at BDD (Specification by Example) and the post by Kalle Mäkelä.

Human-friendly specifications are the key to better software (Kalle Mäkelä, LinkedIn:kallemakela)

---

[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] Status of Specification by Example

It is not easy to recall how I learned about Specification by Example. I think I read Gojko Adzic’s book “Bridging the Communication Gap” somehow at the same time as I started developing SpecFlow. At the time when Gojko was preparing the “Specification by Example” book, I had already had some project experience with BDD and SpecFlow and I got invited to share my thoughts in the book. At that time the exact relationship of BDD and Specification by Example (SbE) was not that explicit and there was no consensus about it. It was clear however that the two concepts were going to the same direction. (Today I would say they are the same.) 10 years later, a survey was conducted by Gojko to assess how we stand with SbE (and BDD) today. The goal was not to measure how wide spread these methodologies are, but to see how SbE has changed and what the current focuses and challenges are. This is definitely an interesting read for all BDD practitioners.

Specification by Example, 10 years later (Gojko Adzic, @gojkoadzic)