This matches my experience. I used to somewhat blame the business folks for being too lazy and/or pompous to bother with their side of the bargain, but I've come to think it's just generally a solution to the wrong problem. The hard part is correctly translating from what is asked for to what is implemented, and executable requirements don't have anything to say about that step. In cucumber, I can take any arbitrary Given / When / Then statement and implement it in any way, including ways that are completely wrong and (worse) ways that are subtly wrong. The translation code just becomes yet more code that may or may not be correct, and in my experience, it can be a lot of code. When you find yourself wanting to write unit tests for your acceptance test pseudo-english translation layer code, you're deep in a rabbit hole.

i think this (the parent post) is truth: i've had conversations a/b behavior specification where edge cases simply aren't taken into account. so the specification would say, for example

"it does this when anyone clicks a button."

whereas there's often some implicit question, like

"what happens when two people click the button at the same time?"

and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.

In general, BAs should not be writing the stories, but they should be able to read them together with the developers.

I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.

The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.

I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin-style story.

But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.

This is my experience as well. Cucumber and the like sound like a way to get 'the business' involved more, but in practice the cucumber files just become yet another thing that the developers or testers have to write. At which point you are better off with more traditional testing methods.

> the cucumber files just become yet another thing that the developers or testers have to write

yep, if (and it's sounding more and more like "when," even outside of my anecdotal experience) that decision is made, there's not much point in using cucumber or similar.

i was kind of hoping someone would say, "yea, our product manager writes domain-specific specification files, and the workflow is so much easier!" ... but no, i'll just continue being mildly cynical a/b the role of developers in industry.