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:
- The user based view where we ignore which systems perform the function.
- The system level view where we describe the behaviour of a system as it interacts with its users, and with other systems.
- 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:
- 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.
- We design the output and validate it with the user.
- 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.
- 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:
- Mobile App
- Order System
- Fulfillment System
- 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.
January 27th, 2018 at 5:36 pm
[…] are three levels of scenarios in BDD. In this post I will describe the interactions between the levels to show how the scenarios […]
January 28th, 2018 at 10:02 am
The very last example should actually say “NOT logged in”
January 28th, 2018 at 10:51 am
Hi Doc, Thank you for the heads up. It’s fixed now. 🙂
January 31st, 2018 at 5:48 am
[…] BDD Done easy – The three levels of BDD Written by: Chris Matts […]
February 13th, 2018 at 12:59 pm
[…] BDD Done easy – The three levels of BDD (Chris Matts) […]
March 11th, 2018 at 5:14 pm
[…] can then work backwards to describe the behaviour of the system using the Given-When-Then format to define the process that populates the required data. (See here and then here […]
March 23rd, 2018 at 6:18 pm
[…] development methodologies Given: I have 15 minutes spare time and: I can use a browser to get to BDD Done easy – The three levels of BDD — The IT Risk Manager Then: I should learn enough to talk about BDD and: Discuss it with others But: Maybe no one […]
May 4th, 2018 at 9:24 am
[…] BDD Done easy – The three levels of BDD (Chris Matts, @PapaChrisMatts) […]
January 16th, 2019 at 2:37 pm
[…] BDD Done easy – The three levels of BDD (Chris Matts, @PapaChrisMatts) […]
February 9th, 2019 at 5:46 pm
[…] Ilona holds a three amigoes session with the development team to establish the stories needed to automate the tests and implement the code. The stories link to the feature […]