The monthly dose for BDD addicts… In July #bdd, #specflow and #cucumber stories by Lisa Crispin, Cucumber team, Liz Keogh, Thomas Sundberg, Mark Winteringham & me.
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the June issue?)
Dear BDD Addicts,
Similarly to 2016, for July I have prepared a little bit of retrospect. My goal was to review which posts have got the most interest in 2017 so far. This way you also get some good BDD readings for the summer holidays and also if someone just joined during the year, or missed a few issues, they can still catch up.
In 2017 we have published 31 posts from 24 different authors. From these I have picked the top 6 based on the clicking ratio of the email newsletters. (When an author appeared twice, I chose only one of the posts – if you are interested in the details please email me and I send you the stats).
The newsletter will go on, so still, if you find any interesting article, email me the link to bddaddict@specsoutions.eu. I hope to see many of you at the Agile 2017 conference next week, please tweet me, so that we can have a drink together. Also stay tuned for our new book (http://bddbooks.com), which we are going to release as beta during the conference.
Enjoy the summer! Here is your monthly dose!
[Process] Specification: The Good, the Bad and the Ugly
Regardless whether you are on an agile project or something not-so-agile yet, you have to make decisions regarding the solution you provide for the business problem. These decisions might be more related to the details of the requirement or they might be related to the technical solution. Discussing these during the requirement or design meetings is fine, but we also need to preserve these decisions in some form. Classic documentation easily gets outdated and takes a lot of time to put down and maintain. Many technical decision can be “documented” with clean, self-documenting code and unit tests. With BDD, we try to use the scenarios – the automated tests about the requirement – to document our understanding about the requirements. Thomas Sundberg collected a few thoughts about how to make the scenarios a good specification.
What is the difference between a specification and a good specification? (Thomas Sundberg, @thomassundberg)
[Process] Rules and Examples
We want to find good examples that illustrate the requirements. But where do they come from? It’s easy to ask for an example when we discuss the user story, but for an average size story, you can find so many examples… it’s easy to get lost in them and also hard to see when can we stop the discussion. Structuring the conversation about requirements can help and acceptance criteria (following Matt Wynne’s terminology, I’d rather call them “rules”) are a good starting point for that. But what is the difference between a rule (acceptance criteria) and an example (scenario)? Liz Keogh’s post explains the difference.
Acceptance Criteria vs. Scenarios (Liz Keogh, @lunivore)
SpecFlow Course in London
Eager to learn about SpecFlow and BDD? Now you can join my SpecFlow course in central London!
This is a renewed SpecFlow course targeting the latest SpecFlow and BDD topics; ideal not only for developers but also for automated testers.
See the detailed course outline and book your seat on the event page.
EARLY BIRD TICKETS UNTIL 15th AUGUST!
BDD with SpecFlow for Developers and Testers
[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)
[Test Automation] We miss the undersea tests!
I was working on a bugfix for SpecFlow. A great feature, covered with Gherkin scenarios, but still buggy. How is it possible? Actually, I realized when I started fixing that for this particular feature we only have SpecFlow tests and no unit tests. So while fixing, I was trying to analyse what caused the buggy code and how we could have avoided this. To my surprise, I found that the answer was related to the balance of automated specification (scenarios) and implementation verification (unit tests).
Balancing Scenarios and Unit tests (case study with SpecFlow) (Gaspar Nagy, @gasparnagy)
[Team] Testing is a skillset
There are many discussions about the role of a tester in a modern agile project (it was also mentioned in the Cucumber Podcast). I think the boundaries of a tester role have been quite much blurred recently. It becomes more and more hard to separate (and dedicate to testers) those tasks that are purely related to quality assurance. But testing is a profession, with a lot of interesting and valuable knowledge and techniques. By removing the testers from the team, we would miss these. Lisa Crispin is analyzing about how testing can be extended to the entire team and shows an example how testing skills can be built up.
When the whole team owns testing: Building testing skills (Lisa Crispin, @lisacrispin)
source: https://cucumber.io/blog/2016/08/31/cucumber-anti-patterns-part-two
[Process] Even more anti-patterns
The “Cucumber anti-patterns (part one)” was one of those that received the most interest from bdd addicts in 2016. Fortunately, we aren’t left without further hints that should be avoided for the sake of a successful BDD implementation. Part two has been also posted! Do you agree? Do you have further “don’t”-s? Write about it! (And send me the link!)
Cucumber anti-patterns (part two) (Cucumber team, @cucumberbdd)
