BDD Gherkin definition of un-gherkin-like work

Question

We are dealing with the split of work which, in the old process, would have all been one big task; Now, (under Scrum) that work is split into stories and refined. We are using BDD to define those stories...

For one particular set of stories - those involved with a particular system - the changes to the system have always been defined in a particular manner. The team members are familiar with it and I am finding it difficult to convert those definitions into BDD. (Also, I do not understand the work they do as it is not in "my wheelhouse".)

I have discussed the BDD approach which the project is now taking with the person (as it happens, a technical BA) responsible for writing/refining those stories and while they are happy with BDD for most of our stories, informs me that it is difficult to do what I am asking; Converting to BDD for this particular system.

The task definitions, generally, involve defining the storage of database-like data and schemas, the nature of requests and responses into and out of the system to get that data and changes to the existing setup.

To be fair, if this were work defining changes to an existing MS T-SQL database I would also find it difficult to provide BDD stories.

TL;DR: How should one define BDD stories which specify technical changes to systems such as databases using gherkin? Is this even the appropriate approach?

Answer 1

It sounds like you are using Gherkin while missing some of the BDD.

Behavior-Driven Development should express application behavior - preferably that the customer can see. This will inherently cut across different technical areas. You shouldn't need technical expertise to write those scenarios and they shouldn't be implementation specific.

For example, if you had something like:

Given I'm a registered user
And I'm on the user info page
When I change the address field
And I Save Changes
Then I should see the new address in my user info

If you need DB changes to make that happen, then you make the DB changes - that's the team's concern.

Answer 2

The fact that your team has issues with Given-When-Then (GWT) is understandable: it's a cumbersome format - more to write for BAs, more to read for Devs. If your team feels that this is unnecessary - don't use it. You should build the process that fits your team & project instead of blindly following the hype.

The value that BDD-as-a-process sells is that you can re-use these requirements for testing - your Dev or QA team could just take the whole thing as is and automate it. If you don't use this feature of BDD - then there's little value in using GWT for requirements.

PS: you seem to confuse the terminology a bit. Gherkin is a very specific version of GWT format used by testing tool Cucumber. Your requirements most likely don't follow Gherkin while still being written as GWT.