I was reading a comment on the  QA & Test Management Solutions group on LinkedIn this morning.  There was a question with a pain we’ve all felt as testers.

Here is my response, which got rather wordy, so I posted it here.

I would ask for examples. BDD encourages “specification by example” and while not everyone is a fan of the syntax, it can help to be specific (and somewhat rigid)

As a… [user role]
I want to… [do this thing]
So that I can… [accomplish this goal]

If they can’t describe the user and the goal, then maybe the task isn’t important.

Then, you can describe specific scenarios:

Given… [these pre-conditions]
When… [some action is performed]
[with this specific data]
Then… [some result]

And press a little further (though you don’t want them dictating implementation details) to help describe what they expect the result to achieve

Verified by… [these post-conditions]

You can build your test assertions based on the post-conditions.

It should… [have this state]

Have them describe several scenarios until you think you’ve got it or they’re sure they have all the bases covered. Suggest alternate scenarios as you see them and see if they’re valid or important (at the risk of making more work for you). Then give them a time-frame to implement and negotiate features versus time.

It works rather well if everyone is willing to work together and goes into it with an honest and non-antagonistic approach.

You don’t have to use the exact verbiage. Given/When/Then is called “gherkin” syntax (gherkin is a type of cucumber — http://cukes.info.) I think If/Then/Else is just as suitable (and business types won’t even know it’s programming.)

The important thing is the feedback loop of communication and iteration, and examples are a great way to encourage concrete thinking and clarify misconceptions.