1

I am new in BDD, so I am struggling with some basic concepts.

Currently I am creating user stories for simple functionality: Login to a device.
Based on BDD methodology, I have to write user story for each (type of) user separately, so I ended up with this:

As a manager I want to log in so that I can use the terminal.
As a server I want to log in so that I can use the terminal.
As a order taker I want to log in so that I can use the terminal.
As a bartender I want to log in so that I can use the terminal.
As a kitchen I want to log in so that I can use the terminal.

...

For each role and each story I have slightly different scenarios on how to log in and where the user should end up after logging in (based on his status, time of the day, etc...). I think the scenarios are OK.

I am little confused, if this is how the stories should be written?

Thank you

Community
  • 1
  • 1
Grador
  • 15
  • 1
  • 4

1 Answers1

1

The story template:

As a ...
I want ...
So that ...

was originally created in a context of mostly Waterfall projects. In those days, stakeholders only got one chance to request everything they thought they might need before the final release, after which change became expensive.

Now of course it's easier to ship multiple iterative releases, so we try to focus on small things that will make a difference. That template is just there to answer three questions that help sort out what's needed for the release from what isn't:

Who is it who wants this?
What do they want?
Why do they want it?

So if you can answer those three questions, it's a good story. And you know, it's OK for multiple people to want the same thing! As for the template, it's just "training wheels" to help you get used to asking those questions.

When we come to do BDD, a scenario is just an example of how something behaves. So we don't need one scenario for every person if the behaviour of the scenario is the same. We can just pick one as an example.

Given Sue is registered as a server
When she logs in
Then she should be taken to the terminal.

Of course, if different roles get different terminals you might want a couple of these; but if all the different roles get taken to different terminals then probably get the devs to put those in class-level unit tests instead. You only really need one example.

Lastly, don't start with login. Imagine they're logged in (hard-code it if you have to) and work out what they're logging in for. That's a much more interesting scenario.

Lunivore
  • 17,277
  • 4
  • 47
  • 92