The monthly dose for BDD addicts… In April #bdd, #specflow and #cucumber stories from Michael Fritzius, Kim Knup, Jan Molak, Mark Winteringham & me.

Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the March issue?)

Dear BDD Addicts,

Last year I talked at expoQA conference in Madrid, where David Evans, the conference host, was encoruaging us to take the opportunity to be together. “Conference is about conferring”, he said. This is definitely true and I would even extend it: conference is about charging up. Last week I attended the Craft Conference in Budapest. This conference vaulted into the almost-empty Hungarian IT conference space three years ago and it has grown to a big international software craftsmanship conference with almost 2000 attendees. There were many sessions related to bdd, test automation and quality. Stay tuned to the @CraftConf twitter channel as they started to release the recorded sessions already.

Have you been at another conference you think is relevant for other bdd addicts? Please send me the link to bddaddict@specsolutions.eu.

But let’s get crafted now with the monthly dose!

Meeting former colleagues at the Craft Conf

[Process] Bugs: hunt them all down

In the 2016 April issue of the newsletter I shared an interesting approach for managing bugs in an agile team (by Mitch Lacey). Dealing with the issues can cause much trouble if you lose control. You have probably heard about the one already that is probably the most extreme, the “Zero Bug Policy”. Kim Knup and her team did not only try this at Songkick, but also shared the experience they had with using it for some time.

Experimenting with a Zero Bug policy (Kim Knup, @Punkmik)

---

[Test Automation] Striving for quality

One of the fundamental paradox in testing (at least if you articulate it as quality assurance) is that quality cannot be guaranteed, it can be just proved by different methods, skills and allocated resources that you haven’t found anything bad. But it is hard to tell if the methods we used, the skills we had and the resources we allocated were enough. Test automation is one such method, but the goal is to assure the quality. “Automation’s goal is not to be served, its job is to serve.” as Michael Fritzius says in his post, which goes deeper into this topic.

Why Your Automation Is Never “Done” (Michael Fritzius, @Testzius)

---

---

[Learn:SpecFlow] We don’t need no code-behind

Although the code-behind files are the most outstanding difference between SpecFlow and the other Cucumber-family tools, the code-behind files were not a design goal, but rather a compromise we had to make to integrate Gherkin scenarios to the .NET tool chain. But tools are changing and we even have .NET Core that changes the way how developer tools interact with developers. So I’ve got some news that is aiming both. (Sorry for the Pink Floyd fans, it’s always the hardest to make an intro to your own post anyway…)

SpecFlow without code-behind files and a big step towards .NET Core support (Gaspar Nagy, @gasparnagy)

---

---

[Test Automation] When the UI test says: tuttu

There are many articles talking about the danger that comes by focusing too much on automated UI testing. We all know the typical problems with it, like brittleness, long execution time and constant maintenance efforts. Mark Winteringham’s shot post might be still refreshing. Not only because he uses the TuTTu mnemonic (pronounced tutu) to describe this anti-pattern, but also because it focuses on the goals you might want to achieve with UI automation. Thanks for sharing it!

Anti-pattern: Cross browser checking (Mark Winteringham, @2bittester)

---

[Requirements] Scenario decomposition

Good scenarios are expressed at the detail and abstraction levels that are optimally fitting to the requirement they are describing. This sounds nice, but how can this be achieved? And what is the right level of detail and abstraction? And how does that map to the user’s activities? Jan Molak’s post discusses this topic.

User-Centred Design: How a 50 year old technique became the key to scalable test automation (Jan Molak, @JanMolak)

---

---