I’ve used BDD in a few roles, but only once where the entire team had buy-in and practiced it in everyday development (and was used from start to finish of a product). I can’t say for certain if it made us deliver faster than if we had without it, but speed is not where the benefits end.

BDD is a great opportunity to find gaps and smells in the requirements, then seek clarity before you implement and deliver. It’s also a great tool for making the developer think like and end user. Only the developer will truly know all of the condition statements and branches of execution are in their code, so it’s fitting that they’d write the user scenarios for them to ensure it’s fully testable.

Which segues into my next point. Having the PO write requirements in one form (possibly English), then a Developer implement it in their programming language, then having the QA write the test plan in some proprietary tool based on the same requirements, usually results in 3 separate interpretations of the same thing. Most of the time when these 3 are not in alignment, that’s a good source of bugs. Having one language which clearly defines the end user expectations across 3 different roles, allows us to all be on the same page.

I think in a longer time period, it would make product development faster. Especially compared to situations without BDD where requirements gaps/misunderstandings cause a lot of re-work when it’s harder to do later on. Even worse in an already-released product, when half the users ended up relying in the original erroneous behaviour (the bug becomes a feature).

Thanks for the read, and for the opportunity for to discuss this topic. There’s just not enough of us BDD advocates, and I don’t understand the denial of such a great practice.