When I was at the European Testing Conference 2016 in Bucharest, a colleague asked for my thoughts on how they should use Behaviour-Driven Development (BDD). I had to run off and didn't get a chance to elaborate on my view, so I decided that I should write it down instead.

My first thought was pretty simple. As long they were talking, and using BDD as a framework for understanding each other, they were on the right track. They were already specifying
what the application should do by writing Gherkin to capture the conversations.

But writing Gherkin is not the most important part here; it's about creating a common understanding.

This post outlines our favourite Cucumber anti-patterns. There are many ways to use tools poorly and, as the core team behind Cucumber, we've picked up our fair share of bumps and bruises. Hopefully by passing on our own experiences, we can help you steer clear of the most common pitfalls.

Along the way we'll also clarify why these patterns can be so damaging and suggest alternatives we've seen work while training and coaching teams around the world.

This is a two-part blog post based on a conversation between Steve Tooke, Aslak Hellesøy and Matt Wynne on The Cucumber Podcast. You can skip ahead to part two here.

There's no point in hiding it, we think Typeform make awesome surveys. At Cucumber we use their forms for all our customer feedback. It's always a bonus when you work with a team that are building a product that you love.

Late last Summer Matt Wynne headed to Barcelona to help the Typeform team practice Behaviour-Driven Development effectively and implement some core techniques to bridge the communication gap between tech and business teams.

Matt caught up with Aida Manna and Gloria Hornero from the Typeform team and asked how other teams can take pointers from their approach. Here's the conversation.

This article was originally published here.

During the last 6 weeks or so, I've had the pleasure to be working on Cucumber Pro with the team at Cucumber Limited. One of the key thing making this such a good experience has been the way we've been working: Mob Programming.

Before you pull a user story into development, it’s crucial to have a conversation to clarify and confirm the acceptance criteria.

Some people do this during their backlog refinement or planning poker sessions. Other teams have a specific three amigos meeting, specification workshop or discovery workshop.

Whatever you call this conversation, many teams find it hard; it’s unstructured, it takes too long and gets boring. The result is they don’t do it regularly or consistently, or maybe they just give up on it entirely.

I’ve discovered a simple, low-tech method for making this conversation short and powerfully productive. I call it Example Mapping.

This article was first published for the Excelian Spark Magazine.

Introduction​

Developing custom software to support business processes can be a costly affair. Developers often make mistakes because they misunderstand the business requirements. This results in defects that usually go unnoticed until the software has been implemented, which leads to expensive and time-consuming rework, and ultimately causes the software to be delivered late and over budget.

When the software is finally delivered, often the world has moved on, and the software is already out of date.

Behaviour-Driven Development (BDD) is a collaborative approach to software development that bridges the communication gap between business and IT. BDD helps teams communicate requirements with more precision, discover defects early and produce software that remains maintainable over time. The BDD approach enhances agile methodologies such as Scrum or Kanban.

Dan North mentioned at one point in the CukeUp 2015 panel yesterday the notion in theology of a community being a "bounded set." Since Tom Stuart had been gracious enough to invite me to participate in the panel, towards the end of the session I joined the panel so I could expand on Dan's comment. I pointed out that the same theology also talks about the notion of a community being a "centered set." To me, this is what BDD really is: A centered set, rather than a bounded set. In other words, _BDD is a centered community, rather than a bounded community.

It's been 11 years since Dan introduced BDD to me while we were working together at ThoughtWorks, and 9 years since he published the article Introducing BDD.

BDD has evolved a lot in the past decade. Dan's article is still a great read, but when I visit organisations who try to adopt BDD I see a lot of recurring problems. Many people still think BDD is a tool. Many people still think it's about testing. BDD is still poorly understood and frequently misappropriated.

Moreover, we know a lot more about what works and what doesn't work a decade later.

It's time to redefine what BDD is.

Is your team using Cucumber like this?

Fantastic! I hope you're reaping some benefits from that. But you can do better!

According to E. F. Schumacher, there are only two kinds of problems in the world:

• Divergent problems
• Convergent problems

Choosing a new car is a convergent problem. You only need one new car. There are lots of options, and the solution is to whittle down those options until you've found one that meets your needs. Once you're there, problem solved.

If you've never bough a car before, you'll need to research all the different options available. You might also want to consider alternative modes of transport - why do you even need a car? Could you make do with a bicycle or public transport? This is an example of divergent thinking.