2/8 Behaviour Driven Development
2/8 Behaviour Driven Development
A road to effective design and clean code - Dan North
Behaviour Driven Development
This is an introduction to behavior-driven development – an approach to development that improves communication between business and technical teams to create software with business value. This guide is for both technical and business professionals and explores how BDD can benefit projects of all sizes, and how to implement it with confidence. It is structured to reflect the flow of the BDD process.
When launching a new digital project, there can be a disconnect between:
the business being truly able to define the desired outcomes;
the developer’s understanding of what needs to be built; and
the business’ understanding of the technical challenges its requirements may present.
Behavior-driven development (or behavior-driven development) can help achieve all of the above and ultimately, helps a business and its technical team deliver software that fulfills business goals.
What is BDD
Behavior Driven Development (BDD) is an agile software development practice that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.
BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure.
History of BDD
Behavior-driven development was pioneered by Daniel Terhorst-North back in the early 00s, as he explained in a 2006 article called Introducing BDD. It grew from a response to test-driven development (TDD), as a way to help programmers on new agile teams “get straight to the good stuff” of knowing how to approach testing and coding, and minimize misunderstandings. BDD has evolved into both analysis and automated testing at the acceptance level. Liz Keogh, another BDD pioneer, started writing and speaking about it extensively beginning in 2004.
Why BDD?
BDD describes application behavior from a user’s point of view. Overall, the main goal of BDD is to improve the collaboration between all stakeholders involved in developing software and form a shared understanding among them.
Benefits of practicing BDD:
Reduced Rework / Shared Understanding: Concrete examples of expected system behavior foster a shared understanding by being specific enough for developers and testers while still making sense to business participants. Think of a BDD scenario like a bug report that is written in natural language and posted before the system has been implemented. It describes the steps to reproduce (Given/When) and the expected outcome (Then) without the symptoms (unwanted behavior) that usually triggered the bug report.
Faster Feedback: Example scenarios describe focused, granular changes to the system under development. This enables teams to evolve the system in small steps while keeping it potentially shippable, allowing for shorter release cycles and faster feedback.
Effectiveness: Since you extend the system in small increments, you can validate business value earlier and avoid unnecessary features. This prevents gold-plating and makes the overall implementation of the system more effective.
Lower Cost: Driving automated acceptance tests through test-first BDD scenarios is much cheaper than post-automating acceptance tests. Teams practicing ATDD (Acceptance Test Driven Development) use their shared understanding to develop the feature and the test automation, while teams separating development and test automation need to interpret and fine-tune scenarios multiple times. This causes extra effort and can lead to misaligned interpretations. Additionally, test automation based on scenarios that were used to drive the implementation has a better focus and more relevant assertions. This leads to higher test automation coverage and more relevant test automation scenarios, which reduces regression errors and efforts for manual checks.
Single Source of Truth: Specification through examples that are guarded with automated acceptance tests is an always-up-to-date description of the current system behavior (“Living Documentation”). This provides a single source of truth for the team, business stakeholders, and important external parties like regulatory authorities or partners relying on the system specification. Here you can view an example.
User Satisfaction: By focusing on the needs of the business, you get satisfied users — which translates to customer loyalty and better business outcomes. The higher degree of test automation frees more time for manual exploratory testing and yields fewer errors in production, especially when shipping new versions at a high cadence. More frequent, high-quality releases enable rapid response to evolving user needs and dynamic market pressures.
Code Quality: Using Acceptance Test Driven Development has a positive impact on code quality: it promotes emergent design that ensures loosely-coupled, highly cohesive architecture and avoids over-engineering and technical debt. This ensures that a system stays testable and maintainable– and that it can be quickly changed to support new requirements without sacrificing stability.
Principles of BDD:
BDD has three basic principles:
Enough is enough: Advance planning, analysis, and design have diminishing returns. We must not do less than what is we need to start, but more than that is a futile effort.
Delivering value to our “stakeholders”: If you find yourself doing something that does not deliver value or increase your skill/ability to deliver value, quit and do something different.
Everything is behavior (Behavior): Whether at the level of code, application or beyond, we can use the same thought and the same language to describe behavior at any level of granularity.
Behaviour Driven Analysis
We explore how software can help address a business problem by asking, what is known as, 5ws1H. This technique is intended to develop insight and allows us to explore new avenues and better understand existing ones.
We approach BehaviourDrivenAnalysis in a structured way to minimize the risk of missing anything useful. Use Cases are a useful tool for establishing the boundaries of a system, in the sense of understanding what the system is (and more importantly is not) responsible for. A Use Case in this context describes an Actor (someone or something in a Role) interacting with some exposed interface to our system.
The important distinction between behavior-driven Use Cases and the traditional Rational version is that the Use Case must specify the business value of the interaction. At this level, the description of the value can be quite broad or vague, but it must be there (because we will drill down into it later). We use Use Cases as a launching point to understand the value at a finer level of granularity, which in turn allows us to prioritize the delivery of functionality as we go along. We talk about prioritizing later on when we discuss BehaviourDrivenPlanning.
BDD in Example
Imagine that you could describe the most complex of ideas to somebody with a different skill-set without introducing misunderstanding or the wrong expectations.
Misunderstanding and wrong expectations are the primary reason behind overwork and waste in the software industry. Engineers often misunderstand what a business actually wants or needs and business people often misunderstand what engineers are actually capable of.
This all contributes to an environment where the technical team continuously delivers, but does not meet the needs of the business and can miss a number of opportunities. This was always a serious problem, but the growth of Agile has made it much more apparent.
Avoiding misunderstanding is a challenge that is not limited to software development. As humans we have encountered this problem throughout our history; every time people communicate, there is a risk of misunderstanding. The difference with non-software communications is that we have had literally millions of years to come up with a solution. And we did. What is the easiest way to remove misunderstanding? Using examples.
Understanding through examples is one of the earliest learning practices we start with as children to remove ambiguity and provide context to what we are trying to understand. So why can’t we just use examples to remove ambiguity from our software discussion? As a matter of fact, we can.
Imagine we have been given a task to add an ‘include VAT and delivery cost to the total price of the customer basket’ feature to an existing eCommerce project with the following set of business rules:
VAT is 20%
The delivery cost for the small basket (less than $20) is $3
The delivery cost for the medium basket (more than $20) is $2
Can you use this information to deliver a working feature? Of course, you can! But what are the chances that you will get it wrong or that you have not fully understood what these rules mean?
For example, these rules do not specify whether to add VAT before delivery cost to the basket total or after. How should you handle a situation where the basket delivery cost is exactly $20? What happens if there are multiple products in the basket?
None of these questions are fully answered in the business rules or the feature description itself which creates ambiguity, and therefore misunderstanding. But what if, in addition to these three business rules, we provide a set of very simple examples of how the application will behave with them? For example:
Given a product is priced at $15 when I add it to the basket, then the total basket price should be $21
Given a product is priced at $25 when I add it to the basket, then the total basket price should be$32
Given a product is priced at $20 when I add it to the basket, then the total basket price should be $26
When written in this way, the ambiguity around total basket price is completely removed. That’s the beauty of examples. They tackle uncertainty by illustrating business rules in action. In a nutshell, if you now convert these three examples into tests and use those to drive development, you’re doing BDD.
The primary reason why this format is so popular is because it is the natural way people speak. In many cases, when we ask our clients to provide examples of how they expect a particular capability to be delivered, they naturally describe it in a sentence such as: ‘when I do that, then this should happen. Here’s an example of an example:
Feature: returned items go back to stock
In order to keep track of stock
As a store owner
I want to add items back to stock when they are returned
Example: refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock
Example: replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock
When he returns the garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock
This user story identifies a stakeholder, a business effect, and a business value. It also describes several scenarios, each with a precondition, a trigger, and an expected outcome. Each of these parts is identified by the more formal part of the language (the term ‘Given’ might be considered a keyword, for example) and followed by a language that the development team and business created together. In the above example, the ubiquitous language includes terms like ‘stock’, ‘replacement’, and ‘returns’.
The formality of the language used in examples also plays an interesting part in the development process. The example above has an obvious structure that is very easy to follow or break down. That makes it an easy target for automation.
Recommended Reading
BDD in Action: Behavior-Driven Development for the whole software lifecycle — by John Ferguson Smart
https://www.toptal.com/freelance/your-boss-won-t-appreciate-tdd-try-bdd
You might also like :
User Stories Playbook (Pre-Order @50% off)
User Stories and backlog management guide
User Stories and Backlog Management Playbook
Module 1 – Agile Manifesto and Principles
Module 2 – Agile Methodology
Module 3 – User Stories
Module 4 – Epic, Theme and Story evolution
Module 5 – Agile User Stores
Module 6 – The 3-C’s of User Stories
Module 7 – INVEST Criteria for User Stories
Module 8 – User Story Estimation Methods
Module 9 – Exercises and Case Study
This is for you if:
You are a new product manager
You don't know how or where to start
You've started working on the product role but still feel lost about writing stories
You're none of the above but you know someone who is. Gift them!
Thank you for your support, Product Mindset Team.