BDD Spec for a Lift Control System?

[Satyendra Kumar]

Whenever I try to study BDD (Behavior Driven Development) from web, I find just trivial examples such as a calculator or even more dull examples. Since nobody is going to give practical examples that they might have used in real life projects, I am asking this question, which is asked in many interviews : How would you go on designing and implementing a lift control system.

I want to know how an experienced professional with experience in BDD approach this problem?

[aslak hellesoy]

Great challenge Satyendra!

Let's do it together. I would start by making an example map [1].

I did a lot of lift controller exercises in uni twenty years ago, but I have forgotten all of the rules.

Can you help me list some lift rules and possibly some exaples to illustrate each rule? Don't use Gherkin, just use your own words.

If you want to have an idea what happens after Example mapping, have a look at my "Kind of Green" presentation [2]. I'll do my best to coach you through the BDD process in this thread.

[1] https://cucumber.io/blog/2015/12/08/example-mapping-introduction

[2] https://skillsmatter.com/skillscasts/7361-keynote-kind-of-green

Cheers,

Aslak

Creator of Cucumber

On Sunday, 28 August 2016, Satyendra Kumar <kumarsa...@gmail.com> wrote:

Whenever I try to study BDD (Behavior Driven Development) from web, I find just trivial examples such as a calculator or even more dull examples. Since nobody is going to give practical examples that they might have used in real life projects, I am asking this question, which is asked in many interviews : How would you go on designing and implementing a lift control system.

I want to know how an experienced professional with experience in BDD approach this problem?

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordrivendevelopment@googlegroups.com.
Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

[Liz Keogh]

Hi Satyendra,

I ask a bunch of questions:

- What makes your lift system awesome, compared to other lift systems? What prevents you from using an existing piece of software? Is there a context that your lift software works in that other software doesn't? And can you give me an example of that? (This is your riskiest scenario, because it's something that nobody's done before, at least in your organisation.)

- Do your stakeholders trust you at the moment? (For companies who've recently adopted Agile, often there's a big disconnect between the business and development. Or maybe the new thing is security, and the security experts don't trust the devs. Whatever it is, the lack of trust is more risky than any scenario, so we're going to look for a scenario that's interesting but predictable to deliver, to gain their trust, before we do anything else.)

- What other capabilities will your system need?

- With those, you can start fleshing out examples (as Aslak suggested). Don't do all the examples for the project up-front though! Focus on doing enough to gain trust, then the riskiest scenarios. The rest will fall out later. It's usually possible to get most of the capabilities up-front; for instance:

    Be able to come to the ground floor when not used in the morning's busy period

    Be able to distribute themselves evenly during the rest of the day, when not in use

    Be able to go straight to the floor that's been waiting longest in the evening's busy period

    Be able to reorganize according to these rules if one or more of the lifts is out of action

And you can come up with examples of which floor the lifts might go to and when. (I'm making these capabilities up; I'm not a lift expert.)

- Pass the examples around. See if anyone can find an example which nobody else has thought of, or a context, or another stakeholder who has an outcome they need that's been forgotten about.

- Although it's possible to get most of the capabilities, being human, nobody will think of or remember all of them. Hopefully the ones which come out later will be easier to implement and you'll have more options, because you were focused on the riskiest ones to start with. You'll also have learned what you need to about the system, so you'll be much quicker by then.

There's a longer overview of this here.

Cheers,

Liz.

On Sun, Aug 28, 2016 at 5:38 AM, Satyendra Kumar <kumarsa...@gmail.com> wrote:

Whenever I try to study BDD (Behavior Driven Development) from web, I find just trivial examples such as a calculator or even more dull examples. Since nobody is going to give practical examples that they might have used in real life projects, I am asking this question, which is asked in many interviews : How would you go on designing and implementing a lift control system.

I want to know how an experienced professional with experience in BDD approach this problem?

--

You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordrivendevelopment@googlegroups.com.
Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Dan North]

Hi Liz,

That's pretty much the approach I was thinking of, just much better worded. And thanks for the pointer to capability-based planning.

I like that you started by asking whether we need to build anything at all. There's a lovely model I've been using from "Stand Back and Deliver" for deciding at a capability or even product-level whether to build, buy or something else. It's called the Purpose Alignment Model and there is a nice write-up[1] from the guy who invented it. Hat tip to Chris Matts for telling me about it.

I've been using this in programme-level planning to kill off, or at least simplify, huge (£millions) pieces of work in both directions, stopping integration projects where we should be building simple apps, and stopping building where we should be buying-and-forgetting.

Cheers,

Dan

[1]: http://www.informit.com/articles/article.aspx?p=1384195

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.

[Jon Acker]

Hi, I once created such a set of scenarios as an exercise for BDD students (since it's a very interesting problem to model).
Unfortunately, I don't have a copy of them, but the essence of using BDD to create a lift-control system would be this:
Get everyone involved in a room and collaboratively visulaize a possible timeline. 
Consider this: it is a lift control system whose purpose is to serve the people using the lift. For want of a better word, lets call them commuters.
The commuters give the instructions (commands) to the system
Nothing happens unless a commuter gives an instruction (here we start getting into the "rules" of the system)
Therefore the first event on our timeline is a commuter pressing the button to call a lift. (it's important to also solidify and agree on the ubiquitous language here. Do you say "request a lift" or "call a lift"?)
Let's say there's a commuter called Jon and a commuter called Mark. We'll show on the timeline how they give the system commands.
Let's also assume that Jon is on the Ground Flood (we shall say this is the bottom-most floor, Mark is on the 1st floor.
To complicate the picture slightly, for a more interesting timeline, lets say there are two lifts. Lift A and Lift B are both on the 2nd floor. Lift A is always the first to respond.

Each floor has two buttons for each lift, one for calling to go up, the other for calling to go down. Except the top and ground floors which only have one calling button.

 09:45 | <- Jon calls lift

 09:46 | -> Lift A moves down towards ground floor

 09:46 | <- Mark calls lift for Going Up

 09:47 | -> Lift B moves down towards floor 1

 09:49 | -> Lift A arrives at floor 1

 09:50 | -> Lift A arrives at ground floor

 09:51 | -> Lift B opens doors

 09:51 | -> Lift A opens doors   

 

There will be many alternate timelines, giving examples of different situations. From each timeline we can extract scenarios that can become candidates for automation, these scenarios are effectively examples of how the lift control system is used.

Each command the commuter gives the system translates to a When step. 
In each scenario/test you are interested in asserting that the outcomes that are a direct consequence of the command did indeed happen.

Given Lift A was called by Jon, from the ground floor, at 0945

When Mark calls a Going Up Lift from the 1st floor at 09:46
Then Lift B should move down towards floor 1
And the trajectory of Lift A should not be affected.

Etc.

The tricky part I found is - how to make sure all scenarios are covered, what's the minimum number of commuters, lifts, floors etc that  you can use to give all possible examples of system behaviour.