18. Working with BDD (Gherkin Stories)
Overview
Behavior-Driven Development (BDD) is an agile software development practice that enhances the paradigm of Test Driven Development (TDD) and acceptance tests. It encourages the collaboration among developers, quality assurance, domain experts, and stakeholders. Test Driven Development (TDD) mainly relies on the repetition of a very short development cycle, where the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards however, Behavior-Driven Development, primarily focuses on obtaining a clear understanding of desired application behavior through discussion with stakeholders using a Ubiquitous language, which is lucid and easy to comprehend.
Behavior-Driven Development was introduced by Dan North in the year 2003.
BDD, principally being an idea about how software development should be managed by both Business Analysts and QA teams, it also assumes the requirement of specialized software tools to support the development process and for intended use in BDD projects.
Conversational patterns in BDD
BDD is all about the conversations you have, exploring examples (or scenarios) of an application’s behavior, to see if everyone has the right understanding. We’ve got a good chance of discovering what someone else knows, and has perhaps forgotten to tell us, if we start questioning the ways in which our understanding might be wrong. These are two patterns which are commonly used.
Context Questioning
We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”
It might be an additional context, or a context which occurs instead of the one(s) we’re considering. We can ask this question, or we can think of contexts ourselves and ask about those. For instance:
Given a salesperson, Tom, wants to sell three cars, Volkswagen, Fiat and Honda
When Tom uses the application
Then Tom should only be able to see the price of Volkswagen, Fiat and Honda
As a Test Engineer, one will have obvious question “Given I have no cars, what happens then?”
The Head of showroom says, “Who cares? Why are you even using the application? Go & get some clients already!” (He’s thinking of his failing business.)
Even though the behavior of the application is not going to change immediately, still a lot can be learnt about business domain this way.
Outcome Questioning
This is similar to Context Questioning, but instead, we ask.
“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”
For instance:
Given the serverX of shopping site has a problem
When a user bought a gift
Then the user should be told about the problem
You’ll wonder, “Is that all that should happen? I’d be upset if I was a user and this happened a lot.”
My business analyst says, “Well, we’ll still have the details in the system, so you’ll be able to do it again later. Oh, yes! We need to store the details of the gift in our system still, too, but make sure it doesn’t have a ServerX ID so that we can tell it didn’t go through.”
There are lots of other ways to have conversations around behavior. They’ll usually be trying to find missing contexts and outcomes – places where a new piece of behavior happens. These also tend to be the things which business users, familiar with their domains to the point where they don’t think about it, forget to talk about. Developers are pretty good at spotting this, because they’re usually thinking through how they’re going to implement the problem, and wondering what goes on the other side of the “if… else…” statement (even if we’re not meant to be implementing yet, we already are in our heads). Testers are also very good, because they’re used to the kind of things people get wrong when they produce software.
This is why getting all three people – a tester, a developer and a business analyst – is so useful when we’re discussing scenarios. It’s also why it’s so important to have the conversations – because if you’re not having conversations, you’re not doing BDD.
