Every now and then, I keep hearing this idea and how testing teams also want to do it. Even JDs mention BDD as a skill that they expect from testers.
BDD is principally a design paradigm. I feel the extra layers do not help with testing but actually make the automation/system more complex and time-consuming (personal experience).
The idea of breaking down complex testing in readable English is so attractive to people that they just give up the real idea of how testing is actually not about doing simple checks. This also gives wrong notions about testing to some people (especially non-testers).
If you have good stories of BDD, please do share them also.
If you are also suffering from BDD immortals like me, share with me some ideas, or your own stories of how you have convinced people about BDD.
BDD grew out of TDD. In both, the tests are not the point - they are just a side effect.
There is a poor assumption that Cucumber is synonymous with BDD. This is… inaccurate. You can use Cucumber to perform BDD, but you can equally use the same tool to not do BDD. Cucumber is just a tool and like many tools, it can be used for multiple purposes.
You can do also BDD with xUnit. It’s a practice, not a tool. I’d argue that you can do BDD without writing any tests. Tests are not the point. Describing the required behaviour via three-amigos collaboration is the point. Gherkin just breaks down the gap between non-technical domain experts and developers. But you can do BDD without using Gherkin. You can use a DSL to express the behaviour; for example, using abstractions to model the behaviour and implementations of those abstractions to implement tests. But such implementations are not a requirement to enact BDD practices.
I’ve encountered a few variations of BDD over the years.
The better one’s were where whole teams were using them and requirements and design stage. Discussing the product behaves in different scenario’s helped team understanding, allowed the exploration of risk, helped document aligned views with behavior examples.
I like examples, I feel they help with understanding so example driven development in it’s many forms can be useful.
The testing element in the above was at the idea testing level, asking awesome questions around behaviors that help explore potential product risk.
In the above case, the automation in the given, when then format was a decent byproduct.
In other cases I’ve seen it handed down from managers to specific groups, direct to developers or worse direct just to testers. This resulted in a focus on the byproduct. Sometimes the automation was fairly decent but often there were questions down the line, why are we doing it this way, is the value from this approach any better than other automation focused approaches, if I’m doing this solo is there value in the given, when then?
The latter for me had lost a lot of the benefits that BDD was bringing to the other team.
BDD gives an overview of the ‘business’ rules and expectations, that you want from the software. We use it for ‘non-technical’ stakeholders to define and scope what they want from the end product. From a Test(QA) point of view, we then use these as our acceptance criteria to provide evidence that the business is getting what they want.
With BDD being ‘High Level’ it will ensure that there is understanding at all levels of development. This does not of course limit the testing to a ‘few’ rules, it gives a baseline of end-user perception. Like with everything - what happens under the hood so to speak is a lot more complex
Each BDD can be taken as a ‘feature’ which will then of course result in many scenarios to satisfy the feature itself.
I am a fan of BDD. But it is not as simple as ‘Given X, When Y, Then Z’ since we know there are always a lot of ‘Y’ and the ‘Z’ is a large combination of things.
The initial BDD definition is a starting point, for all to understand. Just do not get into the complexities under the hood!
From Holistic Testing of Gregory/Crispin 2023:
“BDD and ATDD are about getting shared understanding about what we are going to build. These
practices can all be considered testing activities since we are testing ideas and assumptions. And
they’re testing activities that the whole team can participate in to help make sure they build the
right thing, in the right way
(BDD-ATDD model in the build phase)
During planning, a team understands the story, by exploring examples and creating acceptance tests showing the intent and scope of the story. Once they have that, the team can get into more detail about building.
Team members, often testers, expand those tests using their own set of tools and heuristics to think of boundary conditions, edge cases and more. They can then pair with programmers to discussion automation. For example, they can decide whether a given set of tests should be created at the unit, API, or workflow level.
Each new automated test is run as the code is written. As each test passes, more code is written until all acceptance tests are passing. Then the team can perform other types of testing needed at the story level, which may be exploratory testing, quality attribute testing, and/or verifying the log data gathered via instrumentation. Once all story-level testing has been completed, the product owner can decide to accept the story.”
Testers publish books, and articles and do conference talks on BDD in the context of testing.
BDD was easily linked to acceptance testing and automated checks. Then because most companies are happy with just this practice, the rest of the testing possibilities vanish.
It’s hard for testers to understand and distinguish its role and the core of testing.
I can’t expect others to make more of an effort.
One project I worked on thought it was perfectly normal to hand the tester working code and the AC from which to write Cucumber stuff because “Cucumber is what our testers use…” What really troubled me was the dutiful and diligent testers were just getting on with it. If you are not questioning that madness what do you push back on?
This is just normalised dysfunction. It does take leadership to confront this. Sometimes the recruitment process will filter out leadership attributes.
I can share my experience of two project. One was a simple fitness/heath blogging site, the other one was a complex trading platform.
In both of them we implemented BDD in below areas.
To document requirements in simple words.
Use these requirement for test automation as well.
Our test automation framework was also written thoughtfully to have all action written as reusable steps
In first one where all the functionality was just simple it helped greatly as feature files act as our test documents that can easily be reviewed by product/dev, and they can update them as well.
In second one where a lot functionality involves complex flows. Requirement written in BDD format do helps testers to understand it easily and reduce back and through between product and QA team. But using those as feature files for test automation resulted in chaos. As we have to write a lot of custom mapping it was an overhead and extra work for QA team and finally we decided to drop it.
So in conclusion what i want to say by sharing this, is that BDD is just a way of process of how our development will be done. i strongly agree with @gregmunt that BDD can be done with any tool (or even without tool),
You just need a way to explain the behaviour of application in easy wordings.
Developers will build feature that will satisfy that behaviour.
The same behaviour will be tested by QA.
That’s it.