BEHAVIOUR DRIVEN DEVELOPMENT AKA BDDSOFTWARE THAT MATTERS

BDD

WHY ? WHEN ?HOW ?

WHO BRING BDD ?

He is a technology and organizational consultant who helps business leaders, managers and software teams deliver quickly, successfully and sustainably. Dan’s background in software delivery, Lean operations, coaching and organizational change.

DISCONNECTS IN LAUNCHING OF A PROJECT

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 their requirements may present.

BDD HELPS TO CONNECT THEM

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 their requirements

may present.

WHAT ?

BDD is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.

KEY BENEFITS

All development work can be traced back directly to business objectives.

Software development meets user need. Satisfied users = good business.

Efficient prioritisation - business-critical features are delivered first.

All parties have a shared understanding of the project and can be involved in the communication.

A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.

Resulting software design that matches existing and supports upcoming business needs.

Improved quality code reducing costs of maintenance and minimizing project risk.

BDD APPROACHES

Practice of using examples written in ubiquitous language to illustrate behaviors (how users will interact with the product).

Practice of using those examples as the basis of automated tests. As well as checking functionality for the user, this ensures the system works as defined by the business throughout the project lifetime.

CO-ORDINATES OF BDD

19.0760° N, 72.8777° E

CO-ORDINATES OF BDD

Starting with a Goal

Impact Mapping

Value and Complexity

Analysis

Planning In Examples

Usage Centred Design

Ubiquitous Language

3 Amigos

Development Through Examples

The BDD Loops

STARTING WITH A GOAL

Every Behaviour Change should help

the Business to achieve its goals

Projects should delivered in sets of

Capabilities aka Working Features.

Understand exactly what you want the software to achieve

from a business perspective.

S.M.A.R.T GOAL

Specific

Measurable

Attainable

Relevant

Time-bound

S.M.A.R.T GOAL“We are going to generate more revenue

by making more sales”

“We are planning to achieve a 15% increase

in revenue through our online channels in 6 months”

Not S.M.A.R.T

S.M.A.R.T

Having a SMART goal not only helps to focus the project, but allows the impact of the project to be measured.

IMPACT MAPPING

Now we have sets our goal its time for Impact

IMPACT MAPPING Don’t add features to applications just for sake of more features. Its not always a case that to achieve a goal you have to add a new

feature. It is important to understand that not all of these features need the

same level of attention, care, or even development practice, and it can be easy to spread the development team’s attention too thinly across an entire backlog.

IMPACT MAPPING

Impact Mapping is a technique that helps you to outline all the alternative ways to reach your decided goal by analyzing users’ behavior. We assume that software cannot achieve business goals on its own. The only way software can get us closer to the goal is by supporting particular human behaviors.

LEVELS OF IMPACT MAP

One or More Ways To Support or Prevent These Impacts

One or More Impacts

One or More Actors

Business Goal

LEVELS OF IMPACT MAP

Customer or Team that could help or hinder the project from achieving the goal.

Actors

LEVELS OF IMPACT MAP

Each actor could have multiple ways to help or hinder achieving the goal, we call

these impacts..

Impacts

LEVELS OF IMPACT MAP

What the project or delivery team can do in order to support or prevent particular impacts from happening.

Support or Prevent Impacts

VALUE AND COMPLEXITY ANALYSIS

Value analysis helps us to quickly identify low-cost, high-value

features in the backlog.

Complexity analysis helps us to choose the right development and

collaboration approach to the project as a whole, as well as each

individual feature.

PLANNING IN EXAMPLESImagine 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

following set of business rules: 

VAT is 20%

Delivery cost for small

basket (less than $20) is

$3Delivery cost for medium

basket (more than $20) is

$2

PLANNING IN EXAMPLES

Big ?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?

PLANNING IN EXAMPLES 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

UBIQUITOUS LANGUAGE

Almost impossible, to form a two-way communication between groups of people that operate in different business spheres.

They can stumble upon situations where both sides use the same language and even words, but imply a different meaning.

UBIQUITOUS LANGUAGE

Share $ Share

Design a share feature

UBIQUITOUS LANGUAGE

BDD attempts to eliminate the cost of translation by reducing the size of feedback loops and using the example-based conversation about each feature before they are built.

But just asking for examples is not enough, because different sides will use different language to produce examples, eventually causing discrepancies. 

The solution for this problem is the concept the BDD community borrowed from DDD (Domain Driven Design): ubiquitous language.

INTRODUCING THE 3 AMIGOS

One of the core ideas behind BDD is that no single person has the full answer to the problem.

INTRODUCING THE 3 AMIGOS

3 Amigos

Business Roles Developer Tester

INTRODUCING THE 3 AMIGOS

Business Roles – Product Owner or Analyst

• Business value and risk evaluation domain.• Their insight and input is extremely important if you want

to deliver software that matters.• These people will generally ask questions like ‘is it

valuable? Do we really care about this?’

INTRODUCING THE 3 AMIGOS

Developers

• In the most part, remain in the so-called ‘solution’ space.• Input will give you an invaluable context into how much

detail the feature should have in order to be implementable.

• Tells if it is feasible .

INTRODUCING THE 3 AMIGOS

Testers• Usually represent the ‘problem’ space.• They see flaws happening in the system even before

development commences.• Plays crucial role while analysing negative impact in

application.• Identifies blanks in requirements.• Even sometimes their remarks can help developers to

understand whether feature is needed to develop from scratch or can be achieved with simple twiks.

3 AMIGOS

The core premise of BDD is not to replace these different expertise, but to move them all in one room and have a meaningful discussion about each feature before development starts. This process is called the Three Amigos or an Example Workshop and must be conducted before the team or a developer commits to deliver the feature in question.

DEVELOPMENT THROUGH EXAMPLES

Feed an example to an automation tool (such as Behat, Cucumber or SpecFlow).

Feature Files

Will transform it into the automated specification.

Step Definitions

Can then use this automated specification to drive the application development.

Development

GHERKIN FORMAT & SYNTAX

Gherkin files are plain-text and have the extension .feature Keywords:

Feature • And Background • But Scenario • * Given • Scenario Outline When Then

FEATUREThe feature keyword is used to group a set of tests

(scenarios) The text on the same line as the keyword is considered the name

of the feature All text between the initial line and a line that starts with

Scenario, Background, or Scenario Outline is considered part of a feature’s description.

It is conventional to name a .feature file by taking the name of the feature, converting to lowercase and replacing spaces with underlines feedback_when_entering_invalid_credit_card_details.feature

COMING UP WITH FEATURES: THINK OF YOUR USERS

In order to identify features in your system, you can use what the authors describe as a “feature injection template” In order to <meet some goal> as a <type of user> I want <a feature>

This is good advice The functional requirements of a system are determined by asking the

question for each type of user

what goals are they trying to achieve? what tasks must they perform to achieve those goals? how does our system support those tasks?

SCENARIOS

Scenarios follow a pattern Configure the system Have it perform a specific action Verify that the new state of the system is what we expected

We start with a context, describe an action, and check the outcome

SCENARIOS Gherkin provides three keywords to describe contexts, actions,

and outcomes Given: establish context When: perform action Then: check outcome

Example Scenario: Withdraw money from account Given I have $100 in my account When I request $20 Then $20 should be dispensed

SCENARIOS Additional steps to the context, action, and outcome sections using

the keywords and and but They allow you to specify scenarios in more detail

Scenario: Attempt withdrawal using stolen card Given I have $100 in my account But my card is invalid When I request $50 Then my card should not be returned And I should be told to contact the bank

These keywords help increase the expressiveness of the scenario

SCENARIOS In creating scenarios, a key design goal (indeed

requirement) is that they must be stateless; as the book says “Each scenario must make sense and be able to be executed

independently of any other scenario” You can’t have the success condition of one scenario

depend on the fact that some other scenario executed before it Each scenario creates its particular context, executes one

thing, and tests the result

SCENARIOS

Having stateless scenarios provides multiple benefits Tests are simpler and easier to understand You can run just a subset of your scenarios and you don’t

have to worry about your test set breaking Depending on your system, you might be able to run tests in

parallel reducing the amount of time it takes to execute all of your tests

SCENARIOS

Having stateless scenarios provides multiple benefits Tests are simpler and easier to understand You can run just a subset of your scenarios and you don’t

have to worry about your test set breaking Depending on your system, you might be able to run tests in

parallel reducing the amount of time it takes to execute all of your tests

To Be Continued . . .