Gáspár Nagy on software

coach, trainer and bdd addict, creator of SpecFlow

BDD Addict Newsletter March 2017

by Gáspár on April 5, 2017

The monthly dose for BDD addicts… In February #bdd, #specflow and #cucumber stories from Ryan Aslett, Lisa Crispin, Neil Drumm, Liz Keogh, Thomas Sundberg & me.

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

BDD Addict Newsletter

Dear BDD Addicts,

Spring has come, bees are buzzing and I’ve also got great opportunities to participate in the buzzing around BDD (what a bad joke!) and especially about the topic how you can use BDD to improve the requirement gathering process. We would like to use examples, but how can these help? So I tried to collect posts that help us understanding this topic.

Have you seen another one? Would you share it with other addicts? Please send me the link with some comments to bddaddict@specsolutions.eu.

Let’s buzz around our 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)



[On Air] A BDD Addict

The Cucumber Team regularly makes podcasts with different people. This is the Cucumber Podcast. This month, it was me whom they invited for a talk. Aslak Hellesoy was the host for the event, Arti Mathanda and Matt Wynne were also there asking interesting questions. We were talking about SpecFlow, the changes in the .NET community, the challenges of open-source projects and many more. So that was me.

SpecFlow with Gáspár (Cucumber Podcast)



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


[Process] Document your BDD

There are quite some open-source projects that use BDD for specification and testing (for example SpecFlow itself). But whenever we are talking about applying BDD to a concrete project, there are many team decisions or team agreements  how we are going to do that. How do we structure the feature files? How do we name the scenarios? What kind of tags do we have? In an open-source project, documenting these agreements might help new contributors. Drupal is a popular open-source content software that also uses BDD and they also have a nice checklist about their way. These are their own decisions (e.g. their step definitions are too low-level in my opinion), but we can learn how to document these agreements from this list. Thanks to Ryan Aslett and Neil Drumm for maintaining this guide.

Building Drupal.org: BDD tests (Drupal Maintainers – Ryan Aslett, @ryanaslett; Neil Drumm, @neil)


specflow


Spec Solutions

Leave a Reply