Use Gherkin syntax for Acceptance Criteria without accompanying BDD tool

Question

Pretty straightforward question:

Does anyone have experience writing or consuming Acceptance Criteria written with Gherkin, but doesn't use a BDD tool like Cucumber, Specflow, etc.? Is this method of writing acceptance criteria beneficial? Are there drawbacks? Are there any good alternatives that you might suggest

Thanks

Answer 1

Benefits of gherkin non-automated:

• Has rigid structure (given/when/then, steps and tables)
• Can be more familiar to QA and DEV
• Easy to put to source control and review changes as textual diffs
• Can be eventually supplied with a glue which would execute those specs against an implementation or a model of such. Although most of the time that would still require quite some rework of the original gherkin scenarios

Cons in comparison to say having those specs in an Excel format:

• Not very flexible
• Less familiar and at times more confusing to the business-oriented collaborators
• No self-validation by execution, e.g. expectations can have simple arithmetic mistakes that later may become very misleading. In excel sheets you can use formulas to indicate the relations between the data and validate it
• The rigid structure is not reinforced by the execution, can quickly become messy and inconsistent

Answer 2

Cucumber won't magically make tests from your Gherkin features.

With all those tools you still have to write the step definitions and the code that actually makes the tests happen and maintain it. None of the BDD tools will help you do that and most of them make it hard to exploratory test.

If the acceptance is a sprint level its going to be harder to have the time to do this well in a short time, you typically need some preemptive development of fixtures to keep the tests arriving at the right speed.

If its at integration level then its slightly easier to achieve but try not to do this with large steps , use smaller tightly focused ones and re-use as much as possible.

The main advantage with BDD is that you can reasonably expect project managers to be able to write definitions with it, this allows you to sign off those definitions as long as you can maintain trust in your codes validation of them. Its not a silver bullet, you should really have some clarification of the terms and meanings with both sides before getting too heavily invested in it.

As you are testing across multiple platforms it can be helpfull to use BDD to focus on a similar experience across all of them, you will probably also find that most BDD parsers won't have the platform flexibility you need so you will need to make your own. This is not that difficult if you have the time but your management will probably not like it.

Answer 3

Gherkin syntax should not be used for Acceptance Criteria. Acceptance criteria is a list of things that need to happen to satisfy the product owner. These may have one-to-many Gherkin BDD scenarios for each acceptance criteria. The other distinction is that you need to have all the acceptance criteria outlined before you can size it and pull it into a sprint or iteration. You do not and probably SHOULD NOT have every scenario outlined before you start working on the story. This leads to big upfront design. Speaking of design, many people misuse the gherkin syntax as acceptance criteria and couple it very tightly to the user interface. These Given When Then scenarios instantly morph into a detailed design. So now we're are designing the screens before we finish writing the story? This is mini waterfall...