We have been working with BDD for sometime now and one issue that keeps cropping up is related to the scope of our scenarios. Particularly when it come to making a change to existing functionality.

As a developer I see the scenarios as being akin to a spec, ie. this is the change that is required. However often they seem to stray into regression or acceptance testing.

So scenario 2 wont require any code changes itself but might indicate a function that also needs testing following a change made by scenario 1 (regression testing). Or Scenario 2 might provide an alternative test to the same function as scenario 1 (acceptance testing).

On the face of it this doesnt seem unreasonable however it greatly increases the number of scenarios which makes them more time consuming to write and makes it harder for the developers to see the wood for the trees.

What should the scope of scenarios be when making a change to exising functionality? Can we have a scenario that specifies a change in generic terms rather than having a seperate scenario for each related function?

1 Answer 1


By and large, BDD should be making things easy to change. As long as you're phrasing your steps at a high enough level then scenarios should be simple enough to manage. Here are my hints and tips for making it more so.

  1. Divide your scenarios up into functional areas - things which share the same "when". You can use this to call out the difference between the contexts, and the outcomes that they produce, so the developers will be able to see and understand the difference more easily.

  2. In any place where your application is no longer changing, move those scenarios and make them run overnight. Anything where the application hasn't misbehaved for a month or so. You can bring them back into the main build if one of them breaks.

  3. Focus on capabilities and business outcomes, rather than smaller-grained individual UI steps. If you add a confirmation box, for instance, you should only have to change the underlying automation, not the way the scenarios are phrased.

You're right that scenarios do eventually become regression tests and acceptance tests. At the beginning, though, they're really there to help a team explore their understanding of how the system should behave. It may be enough, in this case, to say, "It should behave like <this other thing>", and leave the generation of the scenarios for later.

Generally, as long as the developers can derive the scenarios, any way of phrasing the behavior is fine. You don't need to capture everything in a written form, and you certainly don't need to worry about automating it while you're talking about what the system should do.

  • Thanks, I think the key point I am taking from your response is "At the beginning, though, they're really there to help a team explore their understanding of how the system should behave".
    – Si Keep
    Aug 26, 2011 at 16:09
  • Please help me spread this message a bit more widely :)
    – Lunivore
    Aug 26, 2011 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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