Scrum is not Agile! How To Make BDD Toast

A few weeks ago I had a great time talking with Matt Wynne, the author of one of my favorite testing books ever, The Cucumber Book – Behavior Driven Development for Testers and Developers. I reviewed this book a while back, but after speaking with Matt I thought I'd revisit a few things that are covered in his book and go over some others we talked about in the world of Cucumber, BDD and Agile.

First, let's make sure we're talking about Cucumber the tool and not cucumber the vegetable. Some of you may even be asking, “What is Cucumber?”

What is Cucumber?

Cucumber is a Behavior Driven Development (BDD) tool for running acceptance tests. Acceptance tests are a kind of automated test that you write together with a non-technical person/stakeholder on the team. If you are doing Scrum this is most likely the product owner; it's basically the domain expert or business expert who understands what the behavior is that they want you to implement.

This is an old, extreme programming — or TDD technique — that the first test you write is a customer-facing acceptance test. The test describes how the story is going to behave once you've finished implementing it. It defines what a customer is going to consider acceptable. Cucumber allows you to run these acceptance tests by writing test in Gherkin.

Gherkin

Gherkin is a Given, When, Then, English-like, readable syntax that Cucumber uses to write acceptance tests. You basically create a feature file — which is just a plain text file — where you write test cases (called scenarios) in Gherkin. You can then implement these feature files/scenarios with code to automate them.

Each test case in a feature is an example of good behavior of the system. If the system is in this situation and you do this to it, this is what should happen:

BDD It's all about conversations

The key to all this, and the magic of using a tool like Cucumber, is conversations.

When you sit down and work with your customer it is imperative that you define the exact behavior you want. These conversations can be the cause of assumptions and misunderstandings, and very often gaps can occur in your respective understandings of the exact outcome both parties are anticipating.

You get a chance to hash all of this out before you actually sit down and write even one line of code. That's also what the name BDD implies; behavior is what drives your development efforts — not the other way around.

If you can find bugs before you ever write a line of code, you've saved yourself and your team a lot of time and money. Bugs found later in the development cycle take more time and more expense to fix.

TDD and BDD are typical activities that Agile teams may follow, but be sure that you are really doing Agile and not just a practice of Agile, like SCRUM.

Agile!

As Matt was talking to me about Cucumber, the conversation turned to talk of Agile, and he said something that really hit me: Just because a team is doing Scrum does not meant that they are doing Agile!

A common problem Matt has seen in his consulting work is that most teams that think they are doing Agile are really just doing SCRUM, and are not practicing test driven development (TDD).

They may write some unit tests as they go along, but they probably don't write them before they write the code, and they certainly don't write any acceptance tests. If they do write tests that test the whole system integrated, they're usually written at the end of a sprint or even in the next sprint.

Tests are usually written by a separate person or persons within the team –one or more quality assurance people — rather than being written as a develop activity. And it's this approach to quality assurance that is broken!

The “Let's burn some toast” approach

If you have ever been involved in software quality assurance you've most likely heard of W. Edwards Deming. There is a great quote of his that describes the situation most companies find themselves in:

“Let's make toast the American way. I'll burn it and you'll scrape it.”

Using this approach to quality, one would assume that the people making the toast are going to burn it, and then you'll have to pay a bunch of people to detect the burnt toast and then scrape off the mess, as opposed to actually assuring that quality is being infused into the toast as it is being made.

You're making sure that you are actually creating a quality thing as you go. This is the advantage of doing test driven development. It keeps you honest about where your defects are and you often get to see the defects before they've been written.

This allows you to think things through a bit more. It also helps to work at a more honest development pace because you're fixing defects in a much tighter loop than you are if you have to wait days for a QA person to run a test for you and then give you feedback.

In essence, you're fixing the problems while the code is still warm.

How to get started making awesome BDD toast

If you haven't read Matt's book yet I highly recommend that you do. If you don't have time to read the whole book, at least read Chapter Six: When Cucumbers Go Bad to learn all the BDD secrets you'll ever need to know to be successful.

Then, take a listen to TestTalks Episode 35 for a whole lot more BDD AGILE testing awesomeness with Matt Wynne.