Dear BDD Addicts,

It’s the second week of October and the newsletter is not out yet! I have deeply dived into the conference and training season. Sorry for not writing earlier, but this does not mean that there is nothing to say! Fortunately there have been a plenty of interesting posts and articles about BDD, agile testing and test automation, making it difficult again to make my selection.

What happened in September? Believe it or not but SpecFlow celebrated its 10th birthday! It is so hard to believe that the small tool I put together quickly 10 years ago (just to be able to see if BDD could help our project) is used by so many people nowadays. But of course this would not have been possible without the people supporting the open-source project, and TechTalk who sponsored the project right from the beginning. Special thanks goes to Andi Willich, who is leading and coordinating the project nowadays. I will have a dedicated talk on the anniversary on the P3X conference in London (31 Oct-1 Nov), I hope to see many of you there.

But now, let’s see the monthly dose.

---

[Agile Testing] Case Study: Agile Testing behind the kitchen

I have been lucky to visit a lot of non-IT companies who have realized how good software support can make them stand out of the crowd. I have seen a printing company who became a market leader by fixing paper-positioning errors by rotating the image to be printed; I have seen a company who can speed up the design process of cable-cars with a dedicated software and I have also seen a company who improves the uptime of their instruments by collecting diagnostics data and scheduling the necessary maintenance on time. All good stories. The post by Lanier Norville brings us to the kitchen of a restaurant to show how agile thinking and particularly agile testing and BDD helped a restaurant chain.

From Cold Fries to Broken Code: Why Agile Testing Matters at Chick-fil-A (Lanier Norville, linkedin:lanier-norville-73729a6)

---

[BDD] For a better sprint planning meeting with Example Mapping

I was in a rush when I saw the new post by Andy “Professor Pandy” Knight. I immediately felt addressed, because I have been participating in long, boring and exhausting Sprint Planning meetings far too many times. We (me and the teams I worked with) have found a solution that has turned out to be very effective. We turned the meeting into a structured conversation that was guided by examples and suddenly we got much more efficient both at the meeting but also during the sprint. Later Matt Wynne showed the concept of “Example Mapping” that was essentially the same as what we did, but with a nice visualization of the progress with cards. I1ve kept sharing this since then (the Discovery book also discusses it in details)  and I am happy to see that more and more people observe the same benefits.

Sprint Planning sucks. Can it be fixed? (Andy Knight, @AutomationPanda)

---

---

[BDD] Good Gherkin, Good Automation

I’ve shared a couple of posts about issues that can arise by misusing Cucumber as a test automation tool rather than a tool that supports the BDD process. When I talk about writing a good, business readable scenario, I sometimes get the feedback that this way the automation is going to take more time. The reality is that in the end it does not take more time and even more importantly, the automation solution will be better! This is also what Angie Jones is explaining in her post.

Writing good Gherkin enables good test automation (Angie Jones, @techgirl1908)

---

[BDD] BRIEF is good

I have shared my post about the BRIEF principles we collected with Seb Rose for the Formulation book. While these principles are not new, the BRIEF acronym makes them easier to remember and easier to apply. Seb summarized the principles in a post recently. Please check them out.

Keep your scenarios BRIEF (Seb Rose, @sebrose)

---

[TDD] Is there a problem with TDD?

I mainly teach BDD, but BDD focuses on the outside behavior and will not directly help you to make your code and the inner structure of your code better. For that I use TDD. Since these two “DD”-s work well together, sometimes I teach both of them. I have to say that understanding and applying BDD seems to be easier for the people than TDD. I was thinking a lot why it is like that and probably there is no single answer. Both techniques require to think a bit differently than before, but for BDD the business expectations are there to guide you, however, with TDD more-or-less you have to guide yourself. The post by Dave Nicolette (neopragma) goes a bit deeper into this and tries to analyze why it is harder to apply TDD. It is a subjective summary. You might not fully agree with all its statements, but it is definitely worth reading and think it over. How could we make the application of TDD easier?

Against TDD (Dave Nicolette, @davenicolette)

---

[BDD] Who is the target audience of the specs of an API project?

APIs are all around us. There are projects that use APIs for internal communication, there are projects that expose their services also through APIs and there are even projects where the only public interface is an API. How should we specify the requirements of those projects? The specs (e.g. the BDD scenarios) should be readable by the stakeholders of the system. The users of an API project are developers who need to integrate the API with their solution. So obviously they are interested in the techy part of the interface as well, like the exact endpoint, the query parameters, the returned status codes and the structure of the JSON/XML payload. So it seems to be fair to expose these details in the specs. This is what a new open-source project, BAT supports. But be careful! You should always be clear what you want to illustrate with a scenario. If you are focusing on the behavior of the API (what responses it gives to the given input and why), going down to the HTTP details might be too low level, and it might focus too much on the mechanical details instead of the intention. (You might have heard of web_steps, that provided similar keywords for web automation and almost killed BDD…) So I am sharing this announcement with a warning. Try it, use it for illustrating the technical details of the API, but not for exposing the business rules.

Introducing Bat: Behavioral API Tester (Phil Mander, @philmander)

---