QASymphony / Blog / Breaking Down Behavioral Driven Development “BDD” PT1
Breaking Down Behavioral Driven Development “BDD” PT1
Hey everyone, welcome to another edition of Whiteboard Friday! Today we’re going to be talking about Behavioral Driven Development, aka BDD, what it is and how it compares to a traditional development process. Enjoy!
Hey, everyone. Welcome to Whiteboard Friday, and today, we’re going to be talking about behavior driven development, which is also know as BDD. And in the Agile space, the testing space, the development space, BDD is a hot topic right now. It’s been that way for a long time, but it’s catching on more and more. You can find many YouTube channels out there that are solely dedicated just to BDD.
But what a lot of people think about BDD, they think about automated testing or automated acceptance-type testing. They think about words like Cucumber and JBehave, these types of automation tools to do acceptance automation testing. However, that’s not really what BDD is. There’s aspects of BDD that incorporates automated acceptance testing. We’re going to talk about that today.
But really, BDD is a technique. It’s a way to establish collaboration between your product owner, your tester, and also your developer and some other stakeholders. It’s a way to get to and find and drive value in the product you’re trying to deliver, rather than having a siloed approach, which we’re going to talk about, which is an older way of doing it or the traditional way of actually developing software.
The way we’re going to go about it today, is we’re going to talk about the traditional development software process. People that use this in Waterfall or they still are using it in Agile, they seem to can’t really get away from it. And then show that in comparison with BDD and how that process is a little different. A say a little bit, but there’s little things in there that we’ll catch up on, and words I’m going to say that seem like they may be small, but really, it all revolves around that collaboration piece that’s missing in this traditional software process.
So let’s talk about that and then head over to talk about BDD and how that can add value to your team. So, a traditional software development process. We’ve got this all clearly outlined in nice colors and figures to help distinguish what’s going on here. But really, what you have is, you have a stakeholder, you have a product owner, you’ve got testers, you’ve got developers, you’ve got technical writers. All these people, right? And how that process actually works is, it starts with a stakeholder telling the product owner what the business needs.
So you have somebody telling somebody, “Hey, I want you to do this,” or “I need this.” Well then the product owner will take that, and in their own space, they will just go off and write requirements. And as they’re writing requirements, the developer and the tester are left out. Same thing with the technical writer, they’re not really involved with that.
And so, what they have to do, what the developer and the tester have to do, is they have to take what the product owner is creating, whatever requirement that is, and what they have to do is, translate the requirement into something they need to do. Which is, for a tester, they need to write test cases. For a developer, they need to write code. Right?
And that goes back into the finished product. And you can see what’s going on here. You’ve got words I was saying like the stakeholder telling the product owner what they want. You have words like the tester and the developer translating, not really knowing exactly what the requirements are, but translating that into something that they need to do.
And also, you have the technical writer down here who’s translating the finished product into something that is more around technical documentation. And so, that translating that occurs…they’re all siloed here; they’re not talking to one another. And that’s going to end up with a finished product that isn’t really discovering and collaborating around the value that you’re trying to deliver for that stakeholder.
So let’s talk about how that’s different than BDD. And before we get going here, we’ve got a quote from Dan North here. He’s one of the actual creators of BDD, a thought leader in that space. And he did this in one tweet. This is a definition of BDD. It’s “using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.” So there’s a couple of things in here which we’ll talk about in this process, but he’s mentioning things like “using examples,” things like trying to “surface uncertainty,” discover value within this whole process so that you’re creating “software that matters.”
And we start out by talking about how we actually do that in the BDD development process. It all starts with the stakeholder and the product owner shifting how their relationship is with one another. So in the traditional way, I was talking about how the stakeholder just tells, “Hey, go do this. Hey, this is my need,” and that’s it, right? Think about, in the military, or you’ve got more higher levels of structure and organization, you’ve got a very strict level of, “Hey, go do this. No questions asked, this is what I want.” Right?
Well, in a BDD process, the stakeholder and the product owner, one isn’t telling the other something. They’re actually starting off and they’re talking about what the business needs. So it’s a start of a collaboration phase. They’re starting to talk about what they need, rather than one person just telling somebody, “Hey, go do this.”
And what happens then is, the product owner takes that, whatever talk they had, and he or she brings it to a collaborative space with the developer, with the tester, so that they can then start talking about, “Okay, what is it that we’re actually going to be developing here?” And what we’re trying to do is establish that collaborative piece to where we’re going to then discover that value that the business wants, by asking certain questions and providing examples of how things were done in the past or how those examples actually translate to a business need that the stakeholder was actually trying to talk about.
And this session, when they’re talking, when they’re collaborating, they’re asking questions like: Why are we doing it this way? Here’s an example of, if I do X and Y, how that responds back to what the business needs. Again, they’re trying to discover that value. This is called the Three Amigos. It’s a Three Amigos session. Anytime somebody says, “Hey, I don’t know what the Three Amigos are,” you can always tell them it’s the product owner, the tester, and also the developer.
And when they’re done with this session…again, they’re all together in one area. They’re not siloed over here, like in a traditional development process. When they’re collaborating together, after they’re done with the collaboration, the goal should be that they produce requirements that are defined in an English format. So they’re producing what’s called scenarios. The scenarios are driven from the examples that they were talking about.
And again, this is something that, in BDD, is common. You’ll hear the words Given-When-Then. Well the Given-When-Then format, that Gherkin style syntax of creating these scenarios, that’s actually what goes into the structure of a scenario. And so out of these scenarios, this is where the automated testing comes in.
So out of that scenario, the tester can use those scenarios as a basis for their tests. And also, the developer can use those scenarios for the basis for their automated tests. And once these automated tests are driven through, they’re ran, they’re passing, they’re failing, or whatever, the automated tests, the reports that they generate are reporting back against the scenarios that they’re testing against.
So it’s not just, “Go off and develop an automated test,” it’s “Go off and develop an automated test so that it’s always going to refer back to the traceability or the coverage we have against the particular scenarios.” And the scenarios, again, they can be rolled up into also covering features. And then the features can be rolled up into covering organizational goals and so on. And so there is an automated testing part of that, and that’s where Cucumber and JBehave come in.
However, if you don’t get the collaboration piece right, if you don’t have an agreed upon set of scenarios that you’re going to automate in this type of syntax, so the Given-When-Then format, then you’d just be creating a bunch of automated tests that don’t actually go back to producing a value that really matters for that product.
So a couple of differences between the BDD process and the traditional software development life cycle that we see here. But the main thing for BDD is, and if you’re trying to get started with BDD, don’t think “I need to go off and automate 50 tests.” The first start in actually getting started with BDD is actually to say, “Hey, let’s call a Three Amigos session,” and move from all of us siloed to all talking with one another together and then figuring out what are some scenarios.
And if these can be automated, great. But guess what? They don’t have to be. It’s not an actual requirement for BDD. A manual tester can certainly create a test and run it and pass it or fail it without any automation going on.
So, again, don’t worry about the automation piece; that’ll come. Just first get started with the Three Amigo process. Start that collaboration. And I guarantee you, the finished product is going to be a lot better than what a traditional software process would have given an outcome for. So this has been Whiteboard Friday. Thank you for joining. We’ll see you next time.