There are three levels of scenarios in BDD. In this post I will describe the interactions between the levels to show how the scenarios can be more easily created.

In the last post, we created a scenario at the User Level…

• 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

…and identified the internal systems that will form the value stream.

We will now use this example to illustrate the relationship between GIVEN-WHEN-THEN scenarios. These are easy to identify when you work backwards. The relationships we will discuss are:

1. The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.
2. For every GIVEN, there is a THEN in another preceding scenario in that system. In fact, the GIVEN in one Scenario, IS the THEN in the preceding scenario.
3. For every WHEN as a result of a message from another system, there is a THEN in the other system.
4. System Level interactions with the user need to be reflected in the User Level Scenario.
5. Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.
6. The start scenario has no context (i.e. No Given).

These rules give clear direction for tooling, especially when combined with the “Business Model” and examples already created prior to the GIVEN-WHEN-THEN scenarios.

I am going to write TODO next to those paths that I am not going to expand in this blog. These paths won’t add any clarity to the point being made and make a handy piece of homework for anyone who would care to follow them through.

We start with rule 1…

The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.

The value stream ends with the fulfillment system:

• THEN the item is delivered to my doorstep
• WHEN the driver hands me the package
• GIVEN the driver has the package
• AND the driver has my address (TODO)

For every GIVEN, there is a THEN in another preceding scenario in that system.

Working backwards, each GIVEN becomes a THEN, namely THEN the driver has the package & THEN the driver has my address

• THEN the driver has the package
• WHEN the warehouse worker gives the driver the package
• GIVEN the account system has marked the items as “Paid For”
• AND the item has been packed. (TODO)

Working backwards again, GIVEN the account system has marked the items as “Paid For” and AND the item has been packed.

• THEN the account system has marked the items as “Paid For”
• WHEN the account system notifies the fulfillment system that the item is “Paid For”
• GIVEN the fulfillment system has the order (TODO)

For every WHEN as a result of a message from another system, there is a THEN in the other system.

The WHEN from the accounts system results in a THEN in the accounts system.

• THEN the account system notifies the fulfillment system that the item is “Paid For”
• WHEN the account system receives a confirmation from the external payment service
• GIVEN the account system requested a confirmation from the Bank’s external payment system.

Obviously, we choose not to describe the Bank’s payment system. However we know that this step maps to the AND the payment amount is debited from my credit card in the User Level Scenario.

• THEN the account system requested a confirmation from the Bank’s external payment system.
• WHEN the account system receives an item purchase request from the order system
• GIVEN the user has valid credit card details stored (TODO)

The WHEN from the order system system results in a THEN in the order system.

• THEN the order system publishes an item purchase request
• AND provides an acknowledgement to the mobile app
• AND e:mails a confirmation to the user
• WHEN the mobile app creates an order in the order system

System Level interactions with the user need to be reflected in the User Level Scenario.

The red output indicates something that iteracts with the user that is not on the user level scenario which means that the user level scenario needs updating.

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

The WHEN from the mobile app system results in a THEN in the mobile app.

• THEN the mobile app creates an order in the order system
• WHEN I place an order
• GIVEN I am logged in
• AND I’ve set up automatic payments (TODO)
  
• AND I have selected a product (TODO)

Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.

So far every “GIVEN”, “WHEN” and “THEN” has been accounted for except for “GIVEN I have an account”. We know we are not finished.

GIVEN I am logged in results in a THEN

• THEN I am logged in
• WHEN I supply the correct username and password
• GIVEN I have an account

A finally we have accounted for all of the “GIVEN”, “WHEN” and “THEN”s.

We may decide to replace GIVEN I have an account with GIVEN I am logged in in the User Level Scenarios for clarity.

The start scenario has no context (i.e. No Given).

Eventually we get to scenario that requires no context in the system.

GIVEN I have an account results in a THEN

• THEN I have an account
• WHEN I create an account

No context is necessary. The account could be created through an API or a Screen or….

We have now reached the Start scenarios. Time to go back and handle all the TODOs, especially the quality paths that I did not even mention.

Although I said there are three levels, I was lying. There are more. However the rules to describe the relationship between scenario in different levels and different systems/components are universal. ( I think ).

In the next post I will discuss some theoretical implications of this on tooling and managing test suites.

If I did not have the flu I would have created more images to illustrate the points. 🙂

My thanks to Mihai Tudor for co-creating this clarity of understanding.

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…

• 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.

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.