44 posts tagged with "BDD"

Over the years that we have been using Gherkin, our approach to writing scenarios has evolved. Because Gherkin is very close to natural language it's very easy to learn, but just like writing reports or stories, it takes practice to do it well. There are three main goals that we try to keep in mind when writing scenarios:

• Scenarios should be thought of as documentation, rather than tests.
• Scenarios should enable collaboration between business and delivery, not prevent it.
• Scenarios should support the evolution of the product, rather than obstruct it.

The following six principles work together to support these goals. To make them easier to remember, we've arranged it so that the first letter of each principle makes up an acronym, BRIEF, which is itself the sixth principle.

Example-guided development is a suggested new catch-all term for the family of practices variously known as Test-Driven Development (TDD), Behaviour-Driven Development (BDD), Acceptance-Test-Driven Development (ATDD) and Specification by Example (SbE) that has been causing a bit of excitement in the agile community. This post aims to give you a summary of where this new term comes from and why it could make a useful addition to our industry's vocabulary.

Software development has transitioned from a waterfall to an Agile approach over the past decade. Since Agile development involves continuous change, testing has become invaluable to prevent these frequent changes from introducing new bugs, or worse, breaking the application in production.

Most developers are familiar with test-driven development, or TDD, but Behavior-Driven Development, or BDD, is often misunderstood. The reality is that both of these approaches have benefits and drawbacks to consider.

In this article, we will look at TDD and BDD, explore the differences, and see how they can work together.

In my work, I come across many organisations who desperately want to enjoy the benefits of practicing BDD, yet set themselves up for failure.

Growing new practices in your teams is a lot like growing plants: you need to create the right environment for the changes to take root and establish themselves. Did you ever bring one of those basil plants home from the supermarket, and three weeks later it was all limp and brown and, well, a bit dead?

That wasn’t the basil plant’s fault.

This was originally posted on my Medium blog.

Example Mapping is a simple but powerful tool. It can frame the conversations that help your team to build a shared understanding about what you are trying to build. It was discovered and popularised by Matt Wynne.

If you haven’t heard of Example Mapping before, Matt’s post Introducing Example Mapping is a great place to start. Alternatively, if you prefer video you can watch Aslak’s Example Mapping webinar.. Both of those resources, and many others online and at conferences, are a great way to understand how Example Mapping works and why it’s useful.

But how do you get started with your first Example Mapping session for you team? Having helped several teams introduce Example Mapping into their practices I wanted to share my tips for getting started.

This was originally published on the Adventures with Agile blog by Simon Powers.

At a well known global investment bank, I was asked to review several product teams and to find out why the teams could not complete stories at the end of each sprint and why there was so many defects coming into the sprint.

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.

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.

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.

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.