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