I like how Dennis describes reasons why testers find BDD appealing:
So, if BDD is indeed not about testing why should I take an interest in BDD as a tester? Well, it is easy to see that BDD can appeal to testers:
Collaboratively exploring what the product should do will lower the risk of building the wrong thing;
Having many different sets of eyes on the ball will increase the chance that requirements are explicit, unambiguous, non-contradictory, correct and complete before we start designing the solution and writing code;
BDD begins with the end in mind: you start with conversations about acceptance criteria from the perspective of all the stakeholders.
Have a read of the article and feel free to share your experiences of using BDD. How might we continue to amplify BDDs benefits? How might we disassociate it as a testing technique?
I believe that one of the reasons people confuse BDD with testing is that lot of popular testing tools are using the Given/When/Then syntax. But Gherkin is just a part of BDD, the main idea behind it is essentially the same as is with DDD and ATDD, to act proactively rather than retroactively, put more focus on getting the requirements done “right” and apply critical thinking as early as possible.
Actually a bit disappointed to read that BDD came from TDD origins, apart from the use of examples I view them as completely different things.
TDD for me was about refactoring and writing clean code and not really testing.
BDD was about team collaboration and discussion, aligning on behaviors to guide development.
So at their primary focus, very little in common at all so I had not seen the connection and had mistakenly thought people were making the connection because they were focused on the byproduct element of automated tests.
Turns out they had a very valid reason to make that connection, may bad. Still that connection has probably baggage BDD usage and misusage.
BDD in my experience did have connections to testing in a different way though, the concept of early “idea testing” can look very close to the collaborative behavior discussions of BDD where the team discuss and align on product behavior they will also talk about risks and ideas around those behaviors which is the testing part.
Hi everyone,
We are currently trialling BDD in our dev team, which is a platform team, supplying tool for product teams to access resources without having to create the access from scratch.
One of the benefits I have seen is the creation of a behaviour profile for the platform. This is really useful when designing the onboarding process for a new product as we can clearly communicate what the platform is currently capable of and it also helps us provide slightly more accurate high level estimates.