Dear BDD Addicts,

I know. It is summertime. But I thought with this last-minute-before-your-(and my)-holiday issue I would share a few articles to think of and to inspire you to try out new things once you are back.

What has happened since the last issue? Probably you have heard… Cucumber Ltd (the company behind the Cucumber open-source tools and their collaboration tool called Jam) has been acquired by Smartbear. With their combined efforts, they will invest more into the open-space tools and work on how Hiptest can be enhanced with the collaboration ideas of Jam. Exciting!

But now… let’s see our monthly dose of BDD, test automation and agile testing…

---

[Test Automation] Test Automation: Think and communicate before acting

It is easy to see that regression testing is useful when adding new features to a product, to avoid the bad side-effects that would destroy your hard-earned reputation. It is also easy to see that manual regression testing does not scale well. Somehow the answer seems to be just as easy for many people: let’s automate! But if you have ever tried blindly rushing into test automation, you know that it is not without challenges and it is just as easy to completely fail with it as easy it sounded to go for it. Bas Dijkstra lists two common reasons for such failures and gives you a bunch of hints to avoid them.

6 Steps for Succeeding with Test Automation in Agile (Bas Dijkstra, linkedin:basdijkstra)

---

[BDD] BDD for complex problems? Break them down!

I have shared already and keep sharing articles about how to write good BDD scenarios (you can also check out the beta of our new book, Formulation). Once you have gathered some practice with it, it is easy to spot out bad BDD scenarios: they are long and full of data. Regarding my experience, these scenarios are written in this form, because their goal or intention is unclear or not communicated well. One reason for this is that they address a too broad target, like an entire user story. In this article, I show a very simple, but very efficient technique for breaking down the stories to rules (acceptance criteria) and illustrate the rules with scenarios rather than the entire story.

Divide & conquer à la BDD: story, rule, scenario (Gaspar Nagy, @gasparnagy)

---

---

[BDD] How many Givens, Whens and Thens are allowed?

On my workshop, I have got this question pretty often: “How many Givens, Whens and Thens are allowed?” When it is said, it sounds like that there is an oracle somewhere who makes rigid rules and if you follow those, you can get the “BDD” stamp. So I refuse giving a direct answer and let them discover the consequences of zero, one or many Givens, Whens and Thens. In the end, they are able to answer these questions themselves. Liz Keogh has shared her thoughts on this topic that contains a couple of good insights.

On Multiple Givens, Whens and Thens (Liz Keogh, @lunivore)

---

[Quality] Costs vs Quality? There is a problem with this question!

We are all talking about quality and especially software quality, so it is rather funny how much this core concept is undefined. We all have a feeling about it but this feeling might be misleading sometimes. I was happy to see Martin Fowler again at Craft Conf in Budapest after a long time and I really liked his thoughts on quality and costs that I would like to share with you.

Is High Quality Software Worth the Cost? (Martin Fowler, @martinfowler)

---

---

[TDD] Seniority is not a good excuse: TDD needs baby steps

The attendees of my TDD courses usually have written a few unit tests already, but they don’t have much practice in test-driven development. Through the exercises and the demos they start to get the practice and once they feel a bit more confident they start to overtake some steps of the TDD rhythm and make big changes without running the tests. And they fail. Not because they just learned TDD. I would fail too with my 10+ years of experience. TDD rules are not about seniority. Thanks to Thomas Sundberg for sharing his thoughts on it.

What is the size of a baby step? (Thomas Sundberg, @thomassundberg)

---