Behavior-Driven Development (BDD) Examples

SAM AND JONAH DISCUSS SAM’S CONCERNS

Setting: Sam’s office, right after the previous meeting. There are large, colorful, highly detailed business process diagrams plastered over the walls, a couple of comfy chairs, and the scent of fresh coffee.

JONAH: So after I ground the coffee I put it in the Aeropress and made my espresso. And the guy in the seat next to me said, “What on earth is that? Some kind of crazy airpump?”

SAM: (Laughs) Seriously? You made your own coffee? Right on the flight here?

JONAH: (Laughs) Sounds a little extreme, I know. I usually take the Aero-press when I travel, but that’s actually the first time I’ve used it and the grinder on a plane. I’ll probably try it on Friday’s flight home—life’s too short for in-flight service coffee. Plus it made the cabin smell so much better!

SAM: Ha! No question.

JONAH: Mmmm…This is great coffee, by the way. What is it?

SAM: Huehuetenango.

JONAH: “Way Way Tenango”? What is that, Ethiopian?

SAM: No, Guatemalan. It’s spelled differently from how it sounds. My wife and I vacationed down there last summer and happened to tour through the area where it’s grown. Guatemala was an amazing experience, I’ll tell you more some other day.

Our day in the village was the highlight, though. We learned so much about the whole coffee process by talking with the people who actually grow it. We’ve been huge fans of Huehuetenango ever since. It tastes so good, and always brings back those same good memories.

JONAH: I bet. I’ll be sure to track down some of my own. Thanks for the tip!

SAM: You’re welcome. Anyway, about that last meeting…I might have come off a little strong in there. I don’t want you to get the wrong idea, I’m actually very supportive of anything that can help us improve. I just don’t like coming into a meeting as the only one not knowing what’s going on.

JONAH: No worries. I figured that was the case. Once again, that was not my intention. I’ll do everything I can to help get you up to speed.

SAM: Great. As a BA, I tend to work with all the development teams, and sometimes it can be a little hard to keep up with every new thing they’re trying. We’ve had some good success with Scrum recently, but we’ve also had a lot of tools and initiatives die on the vine. It’s hard to know ahead of time what’s going to work and what’s not. I’m very pragmatic, so I tend to adopt a wait-and-see posture with new things, to see if they deliver on the promise.

As you can see (Gestures around) I’m very process-oriented and always want to keep the bigger picture in mind, so I’m curious as to how this BDD stuff will fit into how the teams work. If this can help bring more structure and discipline to our process, I’m all in favor of it. Will it do that?

JONAH: I expect so. I’d be very surprised if it didn’t.

SAM: So, I have some questions. First, what’s a feature file?

JONAH: It’s what we use to record our test scenarios.

SAM: What? Now I’m confused again. I thought you, Raj, and Robin were going to be writing up the scenarios we captured in this morning’s meeting; didn’t you say you would be “formalizing them” or something like that?

JONAH: I see. Let me try to clear up some confusion here. Yes, after lunch Raj and Robin and I will do some work formalizing the scenarios we came up with this morning. We’ll write them up in what we call a “feature file,” which is simply a plain-text description of how we expect the feature to work.

We want to do this formalization to clear up any ambiguities in our language, make sure we captured all the important details, and help us ensure we’re all on the same page with you, Mark, and Jane about how it should work. The whole team, actually. It also lets us see if we missed anything.

SAM: Is this where Raj’s vegetable makes an appearance? The “cucumber?”

JONAH: Correct! Though cucumbers, like tomatoes, are actually fruit. But that’s not important right now.

Anyway, I got us a little off track there. Let’s try that again.

There’s a software tool called Cucumber that Raj, Robin, and Jane will use in development to treat our scenarios as a kind of “living specification” for the search feature. With Cucumber we’ll be able to verify the search feature as they write it. In other words, Raj and Robin will code to the scenarios we create, one by one, running them as tests as they do. The feature file is what Cucumber uses as the place to record the scenarios we are using to specify what the feature should do for this story.

SAM: So this “feature file” is a specification document? We’re all in a room just writing a specification document? This is insane. I could do this by myself. We don’t need a meeting with the whole team.

Why do we need any meetings for this? Isn’t this the kind of thing I would normally do on my own as a business analyst? Actually, on Jessie’s team, doesn’t someone write all these details in the product backlog item anyway?

JONAH: Good questions. The last thing we want to do is take up everyone’s valuable time with useless meetings. We are having more meetings than usual at the moment, since we’re getting everyone on the same page with the new techniques, but don’t think of BDD as a series of meetings. It’s more like something a team just does in the course of development. In other words, in the course of the team doing their work, they collaborate; the right people get together whenever they see the need to figure out details.

SAM: OK, good. I have to admit, the meeting we had earlier today was not like many of the boring meetings we have. Everyone was pretty engaged, and I thought we had some pretty important insights and caught some important cases. I could see how it would be helpful to have the developers and testers as part of that conversation.

JONAH: Exactly. And as you’d expect, I’d love to see you all get to the point where you wouldn’t even refer to this sort of thing as “having a meeting,” since with BDD if you’re describing it as a “meeting” it’s usually an indication that something’s wrong with your collaboration.

The goal for this morning’s conversation was to get the right people in the room to discuss what the story meant and how we’ll know it’s done, and to make sure we don’t miss any important details. It’s also critical with a complex business domain like this to ensure the product owner, BAs, developers, and testers—the whole team—are all on the same page with the terminology, how the feature should work, and how it fits in with the rest of the application.

SAM: Yes, there is a lot of complexity in the library domain. More than people appreciate. And all the systems, applications, and integrations we have add a lot of technical complexity too. It’s especially hard to build things on top of our legacy ILS.

JONAH: Ah, OK. So, yeah, I would expect that it’s hard to build new features on your legacy ILS. Most of the teams I work with are doing BDD over the top of some kind of legacy system. It’s a challenge, but it’s not a unique one. Or, as I tell people, “Yes, you are a special snowflake, but not in this area.”

SAM: (Laughs)

JONAH: Jessie’s background in UXD is also very helpful in understanding the flow of user actions and moving beyond just thinking about the role without considering the person using the software and the actual needs the new software feature is intended to meet. I really value having someone who can bring that perspective to the table.

So yes, a feature file is a kind of specification documentation. More like an executable specification. At least, that’s what we’re aiming for.

SAM: I’m not sure what you mean by “executable specification.”

JONAH: In a traditional kind of approach often a product owner, or business analyst such as yourself, would be documenting these scenarios as acceptance criteria, and a tester would perhaps be using them as the basis for their test plan. The acceptance criteria would be captured in the product backlog as stories and their details, and then the test plans and other information would likely be separate supporting documents.

SAM: That’s pretty much how we do it now.

JONAH: Right, and much of that part of the process will not change. However, as you can see, feature files are more dynamic than that. They’re meant to be more than just a document.

With BDD we’re aiming for a living document, one that grows and changes as the software matures.

Because the scenarios run as tests, they end up automating much of what would normally be recorded in manual test plans and regression tests, and because the developers code to the scenarios with Jane’s early input, there is less chance of missing things and introducing bugs.

SAM: OK, but won’t the feature file have to be constantly changing, such as when we update the UI?

JONAH: If we put a lot of UI-specific language in the feature file, then yes, it certainly would. Many teams fall into that trap by referring to “Submit buttons” and the like. But we won’t. We’ll take the time to keep only business language in the feature file. That’s one area where your input will be invaluable. Help keep us honest!

Teams who do a good job at keeping the feature file language focused on business concerns find the scenarios remain much the same over time. The application’s UI may change, and the underlying libraries and applications may too, but the Cucumber scenarios would change only when the actual features change, since they describe the behavior of the application in business language, not the implementation. That’s a lot to think about. Hopefully, I’m not jumping ahead too much.

SAM: A little. But I’m actually more concerned about where I fit in.

JONAH: Of course. Let’s talk about the more important concern, which is your role in this kind of approach.

Let’s see. Mark understands the big goals, your business goals. But he depends on your understanding of the nuances of business processes, systems, and your domain—all the stuff you’re really good at—which is all the stuff that helps the team make sure we have all the right examples for each feature.

SAM: Yes, he does. Mark realizes that no one knows the business processes, technical ecosystem, and even all the library acronyms better than I do. In fact, Mark and Susan kid that after a few beers I might say I understand the library processes better than the librarians do. (Grins) But even I wouldn’t go that far.

JONAH: (Laughs) In terms of what we’re doing this week, this first meeting focused on the happy path, which wasn’t really the part where you add the most value. But the next few conversations are where we’ve got the happy path down, and we’ll be going through all the interesting variations. These will be where you’re really going to contribute a lot more to this, since it’s the part that’s really going to depend on you and what you know.

SAM: This first story seems relatively straightforward to me, which is why I’m having some trouble understanding why we’re taking so much time on it. At least, it’s simple compared to what we’ll have to do for tracking what ebooks each library patron is borrowing.

JONAH: Agreed. This first story is less involved when compared to what is coming. Part of that is deliberate, to help your team get up and running with BDD. To start practicing the skills with a simpler example so it’s achievable. We’ll move to more involved ones once you all have the basic skills down.

SAM: That makes sense. Sometimes I’m the one writing the stories, and sometimes Mark does that. Jessie pitches in, too, from time to time. Will Mark and I be writing the feature files from now on, or will Raj and Robin do that?

JONAH: There’s nothing that says a certain role has to be the one that ends up documenting the scenarios. It’s an important process question, so I recommend we hold off on some questions like that for now and see what the team figures out.

Like learning any new team skill, a lot of this is going to be harder to explain ahead of time than just to learn it together by doing it. I’ll do my best to answer any questions that come up, and I do really understand how you may be skeptical about trying this approach. I certainly would be if I was in your place. Since you trust the team, I’m sure you can also talk with any of them if you have more concerns.

Why not give it a go, at least for the next few sprints, and see how it works out?

SAM: (Shrugs and nods) OK. I’m willing to give it a try for now, support it, and see what happens.

JONAH: Excellent. Thanks again for the brew! See you after lunch.