BDD Done easy – The three levels of BDD

The easy way to do BDD is “Working Backwards“(1). Sadly “Working Backwards” is a principle that few people are aware of and even fewer practice.


The other poorly understood aspect of BDD is that there are three different levels of scenarios(2). The three levels are:

  1. The user based view where we ignore which systems perform the function.
  2. The system level view where we describe the behaviour of a system as it interacts with its users, and with other systems.
  3. The user interaction level where we zoom into a specific micro-interaction between a user and the system.

The User Based View

We work backwards from customer based value to create the user based view:

  1. Identify the value. To do this, we find the value to the customer by creating a mock up of the output and asking them how they will use it.
  2. We design the output and validate it with the user.
  3. We use “Information Smells” (i.e. Work Backwards) to identify the data (examples) and calculations needed to create the output. I normally document the examples in an excel spreadsheet as there tend to be a lot of them.
  4. We then work backwards to describe the behaviour of the system using BDD.

At this stage, we should be describing the system from the users perspectives regardless of the different IT systems and organisations. This is the first level of BDD. Describing the system from the users perspective and these BDD scenarios become the User Acceptance Tests. The examples are likely to be more complicated in their description.

For example:

  • GIVEN I have an account
  • AND I’ve set up automatic payments
  • AND I have selected a product
  • WHEN I place an order
  • THEN the item is delivered to my doorstep
  • AND the payment amount is debited from my credit card

We can express this visually…

Screen Shot 2018-01-27 at 14.59.36

  • The WHEN describes the user input.
  • The GIVEN describes the necessary internal state of the system.
  • The THEN describes the outputs from the users perspective.

The System Level View

A number of systems may be involved in the scenario described above. At the system level, the BDD scenarios describe the behaviour of each system as experienced by the users and other systems.

Consider a company that has a number of systems that form its value stream:

  1. Mobile App
  2. Order System
  3. Fulfillment System
  4. Account System

We start our description of the behaviour of the systems by mapping them to the user view. Every interaction at the user level needs to be replicated at the system level. The “Givens” will be mapped to the systems when we work backwards. Each “Given” will need to replicated at the system level.

Screen Shot 2018-01-27 at 15.08.20

The creation of the GIVEN-WHEN-THEN at the system level will be described in the next post that examines the interaction between the levels.

The User Interaction Level

The User Interaction Level scenarios describe the detail of how the user interacts with the system. This is best illustrated with a couple of examples.

  • GIVEN the user has selected a product
  • AND the user is logged in
  • WHEN the user hits the “Buy” product
  • THEN the system generates a “Buy” order
  • AND it displays the “Buy Order” confirmation screen.

which describes the behaviour when logged in, compared to the behaviour when the user is not logged in:

  • GIVEN the user has selected a product
  • AND the user is not logged in
  • WHEN the user hits the “Buy” product
  • THEN the system displays the “login” screen

Unlike the User and System Level Scenarios, the User Interaction Scenarios are often stand alone rather than part of an overall system description. Organisations try unsuccessfully to assemble a coherent comprehensive test suite out of these fragments of testing.

The next blog will describe the interaction between the levels by describing how to create the Given-When-Then scenarios at the system level.

(1) Working Backwards is a key principle of BDD. Originally known as feature injection, Jenny Martin came up with the excellent OOPSI acronym, and Kamil Nicieja mentions it in his book “Writing Great Specifications”.

(2) Actually there are more than three levels (Thank you to Joe Schmetzer for pointing this out). However from the perspective of BDD, the describing the behaviour of a system and a component are fundamentally the same.

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

10 responses to “BDD Done easy – The three levels of BDD

Leave a Reply to Five Blogs – 31 January 2018 – 5blogs Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: