BDD is a software development process that improves communication between business and development teams. It uses examples written in a ubiquitous language to define desired product behaviors. The examples serve as requirements for automated tests and drive development. Key aspects of BDD include impact mapping to prioritize features, planning in examples with the three amigos (business, development, testing), and developing using examples as automated tests. This ensures the system meets business needs while delivering working software.

1. BEHAVIOUR DRIVEN DEVELOPMENT AKA BDD
SOFTWARE THAT MATTERS

2. BDD
WHY ?
WHEN ?
HOW ?

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

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

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

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

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

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

9. CO-ORDINATES OF BDD
19.0760° N, 72.8777°
E

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

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

12. S.M.A.R.T GOAL
Specific
Measura
ble
Attainabl
e
Relevant
Time-
bound

13. 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
to be measured.

14. IMPACT MAPPING
Now we have sets our goal its time for Impact

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

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

17. LEVELS OF IMPACT MAP
One or More Ways To Support or Prevent These Impacts
One or More Impacts
One or More Actors
Business Goal

18. LEVELS OF IMPACT MAP
Customer or Team that could help or hinder the project from achieving the
goal.
Actors

19. LEVELS OF IMPACT MAP
Each actor could have multiple ways to help or hinder achieving the goal, we
call
these impacts..
Impacts

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

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

22. PLANNING IN EXAMPLES
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 following set of business rules:
VAT is 20%
Delivery cost for small
basket (less than $20)
is $3
Delivery cost for
medium basket (more
than $20) is $2

23. 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?

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

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

26. UBIQUITOUS LANGUAGE
Share

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

28. INTRODUCING THE 3 AMIGOS
One of the core ideas behind BDD is that no single person
has the full answer to the problem.

29. INTRODUCING THE 3 AMIGOS
3 Amigos
Business
Roles
Developer Tester

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

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

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

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

34. 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.
• Developm
nt

35. GHERKIN FORMAT & SYNTAX
 Gherkin files are plain-text and have the extension .feature
 Keywords:
 Feature • And
 Background • But
 Scenario • *
 Given • Scenario Outline
 When
 Then

36. FEATURE
 The 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

37. 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?

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

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

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

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

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

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

44. To Be Continued . . .