Someone told me that out there, somewhere, are people who believe that “Given, When, Then” is the only way to analyse a story. I don’t believe it’s true. Sometimes there are more concise ways to get the same information. For example:
“Refunded or replaced items should always be returned to stock, unless they’re faulty.”
That’s four separate scenarios, encapsulated quite well in a very short sentence!
So why do we emphasise Given, When and Then in BDD?
Well, we can describe the behaviour in a different way. However, when we’d like to know when we’re done, we have to use a concrete example, whether it’s automated or manually driven. The only way to know whether the above sentence holds true for our system – whether the behaviour is correct – is to actually run through all four scenarios. Until they all work, we’re not done.
So, perhaps you, the business representative or analyst, don’t like using the language of contexts, events and outcomes. However, we devs use it all the time, as do QAs. However you get the information, and however you phrase it to us, the examples that you pass on to us define the scope of the story, the detail, and the end product.
An automated example sets up some contexts, causes some events to occur, and checks for certain outcomes (and perhaps then uses the result as the basis for more events and outcomes).
A manual test does this too.
With automation, particularly, it seems that contexts, events and outcomes are frequently reused to create different scenarios. Phrasing things in a way which makes them explicit can sometimes help us to reuse code in our scenarios, making the regression test suite cleaner and easier to maintain. This makes it easy to create new examples for behaviour we haven’t coded yet, which means we know more quickly when we’re done, which means you get your system delivered faster.
If we get the wrong Givens, Whens, or Thens, or we’ve missed a couple of contexts that might lead to different outcomes, then perhaps the system we produce might behave in ways that you didn’t intend, if at all.
You don’t have to be pedantic about the language – it’s OK to balance common sense with detailed explanations, and concentrate on the unexpected and on edge-cases – but if in doubt, you may find that using examples makes things a little clearer.
You may also want to read through our examples when we’re done. Just to check.
Given, When, Then is the format I use for acceptance criteria for stories (and have been teaching in courses for TW). It helps to ensure that each criteria is SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) – especially the specific part. With your example, there are many different scenarios (as you pointed out), which isn’t very specific. Of course, you can have many different acceptance criteria for a story.
The story itself is the part that tends to be more generally described (as a …, I want …, so that …). Eg. As a store manager, I want refunded items to be returned to stock (unless faulty) so that they can be resold.
I like SMART; great acronym and one I hadn’t heard before.
I’ve heard lots of different things referred to as ‘the story’ and would agree (As a… I want… so that…) is a fundamental and important starting point. I call that ‘the narrative’. I’m not bothered either way if you want to call it ‘the story’. For me, the story is a growing thing that includes all the examples, conversations and things we know about it. But maybe that’s just me!
(Who are you, by the way?)