BDD is not about test automation.
Then what is it?
Seb Rose and Gáspár Nagy, authors of the book Formulation: Document examples with Given/When/Then explain.
What is Behavior-Driven Development?
First off, behavior-driven development is about you needing to achieve a shared understanding by having conversations with your team.
You then need to capture the conversations–usually in a feature file.
Once your development team becomes proficient at capturing the conversations, you can then use the tools to automate them to help with acceptance testing.
Why BDD is not the same as Automation Testing
In many cases, the BDD concept comes through the developers or the test automation engineers.
The developers are typically assessing the complexity of something by how elaborate the language is.
And Gherkin is an extremely simple natural language; only ten or so keywords:
- Feature
- Rule (as of Gherkin 6)
- Example (or Scenario)
- Given, When, Then, And, But for steps (or *)
- Background
- Scenario Outline (or Scenario Template)
- Examples (or Scenarios)
There are minimal constructs that you can really have in that; it gives you the feeling that the writing of a BDD scenario with Given/When/Then is easy.
But it’s not as easy as people think.
It’s actually a struggle for many teams.
Part of the problem of getting behavior-driven development accepted in organizations is that so many people have heard about BDD, and a lot of them think that its test automation using given when then, and, testing frameworks like Selenium. This type of thinking gets teams in trouble.
You need to show them straight away that BDD is not about BDD automation testing.
How to write better Behavior Driven Development Scenarios
One way to change this mindset is to use the process of discovery; maybe with example maps or other forms of structured conversation to get to a place of shared understanding.
Doing this will pull everyone in the same direction.
Capturing that understanding will not only help today’s team but will benefit future teams as well as the product owners, business analysts and stakeholders that come along in the future.
One of the thought experiments you can use to really drive this point home is to ask yourself whether you’d prefer to have unreliable documentation or no documentation.
If you were to ask most software engineers, they would undoubtedly say that unreliable documentation is completely useless and that it’s better to have no documentation.
At least then you must go to the single source of truth, which is the running system, to work out what it does.
If you ask developers which one they have, the answer is always unreliable documentation.
Although discovery and formulation don't get there yet, when you incorporate automation acceptance tests correctly, you get to something called living documentation.
This is where the scenarios that you've formulated in business language, which document how the system is supposed to behave on a requirement-by-requirement basis, actually guarantees themselves to be correct because, underneath them, there's automation code that verifies that the system behaves as described.
A side benefit is that this also generates executable specifications.
Concise Cucumber Tip
One way to achieve a better behavior-driven development process in software development is to remember the acronym BRIEF.
B stands for business language. You should use the business language instead of the technical solution language.
R is for real data, which means that it's good. If these scenarios have concrete illustrative data, it clearly shows how the system is going to be used.
I stands for intention revealing, which can get tricky. It basically means that whenever we’re phrasing the scenario, we should focus on what our intentions were for those different things we are doing there, and not so much on the methodical steps.
E stands for essential. We want to keep only essential details in the scenario and push down to the automation layer in the step definitions—all the incidental details that are not relevant for illustrating that particular rule, down to the automation.
F is for focused; that the scenario itself is focusing on a single rule. You don't want to solve all the problems with a single Oracle scenario or something like it, is for focused; that the scenario itself is focusing on a single rule. You don't want to solve all the problems with a single Oracle scenario or something like it.
It’s best to have a small, concise scenario that fits under the screen, and that you can easily share with your stakeholders.
When working with BDD, you’re the one who is formulating the scenarios, and you’re the one who is automating them.
Clear your BDD scenarios of automation details
Another tip is totally to forget about automation testing during this process.
Instead, try to describe what you really want, and try to capture that as quickly as possible to determine whether it conflicts in any way with the automation.
It’s imperative that you forget about automation—at least for the moment.
I'm going to belabor the point now, but it's not a tradeoff, so don’t let the automation intrude into the scenarios. It's just not necessary.
BDD tools like Cucumber and SpecFlow (Behavior Driven Development for .NET) both have various under-the-hood automation techniques that allow you to avoid placing this detail directly into your scenarios.
The goal is like any other basic software engineering coding practice, you want to abstract away the details.
The scenarios are formulated to talk about the intent or behavior.
The details are important, but you don’t need them in the formulation.
Scenarios are not manual tests converted to automated tests
I think the most important takeaway is that for some reason, people think that whoever is transitioning to BDD and they already have some manual test scripts than one easy way to transform, to BDD, to take those manual test scripts and simply transcribe them to BDD scenarios and automate them.
And unfortunately, this is something that experience has shown me does not work.
You can take a manual test script and automate it using Gherkin scenarios with Given/when/then — people do that, but they get into awful trouble doing so, because they end up with something that is just as incomprehensible, only now they have to maintain automation code that is incomprehensible, as well.
Key BDD Takeaway
The main takeaway I want to give you is that behavior-driven development is about a shared endeavor.
It's about reaching a shared understanding.
It's about collaboration.
It's not about unit testing, automation tools, or testing tools.
It’s also not something that a QA or test department can do on its own.
You need to have your development teams involved, and you should have your business or product owners bought in as well.
If you have any people that just say, “Nah, it's not my business.
I'm not interested.
I'm not going to get involved,” heed these warnings, or you will have a very painful time of it.
Listen to the Full Interview on BDD
