Is it appropriate for BDD scenarios to have "click here" style specificity?

I have read a lot of examples where scenarios are stated to avoid any particular user interface interaction, yet tools like SpecFlow would seemingly require this level of detail.

Is it appropriate to require the BA to write a story which contains scenarios at a high level and then work them down to a more technical (and element-specific) level during the 3 amigos phase?

For example, is this appropriate:

Given the user is on /search
And the "Jeff" is entered into the field "searchinput"
When the "Search" button is clicked
Then the page displayed is /results/Jeff
And the fields displayed include "Name"
And the second field displayed is "Post Code"

The story example and tooling example on this page appear to be incompatible if we are trying to get from one to the other (ignoring the fact that they are in very different business processes): https://en.wikipedia.org/wiki/Behavior-driven_development

  • I would say that the detail of BDD scenarios should be at that level where the business value is displayed well and understandable for business people. Deeper than that can be important for technical guys. This is an abstraction. But, if you automate these scenarios then you have make them more detailed to be able to reuse the steps well and push down the maintenance cost. Aug 4 '17 at 11:21
  • Thank you. For non-technical business people writing these stories and technical developers performing the work, at which point - and how - is this gap bridged?
    – Matt W
    Aug 4 '17 at 11:29
  • I believe it depends case by case. I know business people who are comfortable with more details and I also know business people who are not. We need to find the right balance to do our delivery job and keep them happy. Aug 4 '17 at 13:30

Your level of behavior is right. Most practitioners (myself included) would recommend that you phrase it in a way that is less implementation-specific. For example:

Given the user is on the search page 
When the user searches for "Jeff"
Then the results page is displayed
And the "Name" field is displayed with the value "Jeff"
And the "Post Code" field is displayed with the value "80273"

This is implementation-agnostic which means that you don't need to know the implementation ahead of time and you can tackle multiple implementations (web and mobile for example) more easily.

I also adjusted the wording so it is easier to automate. If a PO or some other non-technical person is writing the test, I wouldn't expect them to know to make some of these changes. I'd expect the developers to recognize them and help there. Specifically, the last two lines are now the same pattern and easier to automate and the whole scenario could be run with a lot of different values plugged in for each of those items in quotes very cleanly.

Finally, you asked in a comment how you bridge the gap. My recommendation is to write the test case before you know the implementation. That forces you into more of this implementation-agnostic language.

  • Thank you. My concern is that I'm writing these stories in a (fairly) different environment than I used to work in. The main issue is that the people who know the systems inside out are the BAs and are not Agile. The developers, who are (mostly) agile, don't know the systems. My aim is to using scrum to help everyone learn while being productive about it. (The typical problems occur, as I'm sure you can imagine.)
    – Matt W
    Aug 4 '17 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.