Behavior-driven development

Benefits for developers, business and QA

Presenter: Velibor Mandzo

Software development : Waterfall to BDD ~ 30min
BDD: introduction, requirements, benefits ~ 30
min
Break ~ 10 min
Gherkin: syntax, usage,Tamedia example ~ 90 min
Break ~ 30 min
Quality Assurance ~ 30 min
Hands on practicing ~ 45 min
 Software Development
Software development : Waterfall Life Cycle
to BDD -
~ 30min
Waterfall
BDD: introduction, requirements, benefits ~ 30
min
Break ~ 10 min
Gherkin: syntax, usage,Tamedia example ~ 90 min
Break ~ 30 min
Quality Assurance ~ 30 min
Hands on practicing ~ 45 min
 Project
Software Management
development Bermuda
: Waterfall Triangle
to BDD ~ 30min
BDD: introduction, requirements, benefits ~ 30
min
Break ~ 10 min
Gherkin: syntax, usage,Tamedia example ~ 90 min
Break ~ 30 min Scope

Quality Assurance ~ 30 min

Hands on practicing ~ Quality
45 min

Cost Schedule
 You can
Software development choose to
: Waterfall only
BDD ~ 30min
BDD: introduction, requirements, one…
benefits ~ 30
min
Break ~ 10 min
Gherkin: syntax, usage,Tamedia example ~ 90 min
Break ~ 30 min
Quality Assurance ~ 30 min
Hands on practicing ~ 45 min
Software developmentStacey Complexity
: Waterfall to BDD ~ 30min
BDD: introduction, requirements,Matrix
benefits ~ 30
min
Break ~ 10 min
Gherkin: syntax, usage,Tamedia example ~ 90 min
Break ~ 30 min
Quality Assurance ~ 30 min
Hands on practicing ~ 45 min
Iterative Waterfall
 Scrum Process

Sprint

Sprint
Review
Daily
Sprint Scrum
Product Retrospective
Backlog

Sprint
Planning Product Increment
 How to write good user story
A user story template often uses the following
type of format:
As a <role>, I want <feature> so that <reason>.
Examples of user stories:
As a user, I want to upload photos so that I can
share photos with others.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 INVEST in a User Story
A user story template often uses the following
type of format:
As a <role>, I want <feature> so that <reason>.
Examples of user stories:
As a user, I want to upload photos so that I can
share photos with others.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 Kanban

A user story template often uses the following

type of format:
As a <role>, I want <feature> so that <reason>.
Examples of user stories:
As a user, I want to upload photos so that I can
share photos with others.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 The philosophy

Behavior Driven Development (BDD) is an approach that consists on

defining the behavior of a feature through examples in plain text.
A user story template often uses the following
These
typeexamples
of format:are defined before the development starts and are used as
acceptance criteria. They are part of the definition of done.
As a <role>, I want <feature> so that <reason>.
That’s a very of
Examples powerful approach that we can use in our development process.
user stories:
Examples
As a support the conversation
user, I want and help
to upload photos theI can
so that cross functional team
(marketing, productwith
share photos owner, developer, user, qa…) to create a shared
others.
understanding of what should
As an administrator, be developed.
I want to approve photos
That’sbefore
a greatthey
way are posted sowaste
to minimize that Iand
canavoid
makedevelopment
sure of features
they are
that nobody wantappropriate.
or that do not meet the business expectations.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 Cultural shift
In the past decades, software development lifecycle has been structured
with silos.
Every Asilo comes
user storywith its repository.
template often uses the following
type of format:
As a <role>, I want <feature> so that <reason>.
Examples of user stories:
As a user, I want to upload photos so that I can
share photos with others.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 Cultural shift
Agile development has changed the game and broken the silos. There is also a lot of buzz
around agile testing.
A user
But BDD storythan
is more template often uses the following
just testing.
type of format:
Trying to match with the concepts of the old world is useless. It is like applying equations
As a <role>,
of the classical physics Itowant <feature>world.
the quantique so that <reason>.
Examples of user stories:
When doing BDD, specifications and tests become two sides of the same coin. You define
As a user,by
your specification I want to upload
examples and photos so that
at the same I can
time you get your tests. These
share
specifications photos
become with others.
executable when the examples are automated.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 BDD
Behaviour-Driven Development (BDD) is a collaborative approach to software development that
bridges the communication gap between business and IT.
BDD helps teamsstory
A user communicate
templaterequirements
often useswith the
morefollowing
precision, discover defects early and produce
software that remains maintainable over time.
type of format:
It helps teams create business requirements that can be understood by the whole team. Specifying
As a <role>, I want <feature> so that <reason>.
examples uncovers misunderstanding people might not even be aware of. Teams that practice BDD focus
Examples
on preventing defectsof userthan
rather stories:
finding them.
BDD focuses Ason:
a user, I want to upload photos so that I can
share photos with others.
Where to start in the process
What toAs testan
andadministrator,
what not to test I want to approve photos
How much to testthey
before in one goposted so that I can make sure
are
What totheycall the tests
are appropriate.
How to understand why a test fails
As rework
This leads to less a user, andI quicker
can indicate folders not to backup
time to market.
so that my backup drive isn't filled up with
The two main practices in the BDD approach are discovery workshops,
things I don't need saved
which bridge the communication gap between business and IT, and executable specifications.
 Discovery Workshops

Discovery workshops (or Specification workshops) are short and

frequent meetings where business and IT meet to gain a common
A user story template often uses the following
understanding of how the software should behave.
type of format:
BusinessAsstakeholders and IT representatives
a <role>, I want <feature> so that <reason>. (developers and
testers) meet to
Examples discuss
of user features or user stories.
stories:
As a user, I want to upload photos so that I can
These roles
shareare often
photos called
with others.the “Three Amigos”. They have
conversations about concrete
As an administrator, I want examples that illustrate the business
to approve photos
rules andbefore
acceptance criteria.
they are posted The Ipurpose
so that can make of these examples is to
sure
they are appropriate.
trigger discovery through conversations, but also to define how
As ashould
the system user, I can indicate folders not to backup
behave.
so that my backup drive isn't filled up with
things I don't need saved
 Discovery Workshops

Conversations about concrete examples help expose misunderstandings

between people with different perspectives. Some questions can be answered
immediately; otherwise
A user story theyoften
template can be written
uses down and analysed further after the
the following
workshop.
type Discovering
of format: misunderstandings is one of the key goals of BDD!
Discovering
As athem early
<role>, helps
I want prevent
<feature> sodefects.
that <reason>.
Examples
Discovery of userallows
workshops stories:
business stakeholders to verify that the developers
have understood what
As a user, theytoare
I want supposed
upload to so
photos build
thatbefore
I can they build it. It also
share stakeholders
gives business photos with others.
better insight into the size and complexity of the
story, based on administrator,
As an the number of Iquestions and examples.
want to approve photos
By gettingbefore
testersthey are posted so that I can make sure
involved before the software is written, they can focus their
they are appropriate.
effort on helping developers prevent defects rather than finding them weeks or
As a user, I can indicate folders not to backup
months later.
so that my backup drive isn't filled up with
things I don't need saved
 Executable specifications

The concrete examples that are created can be used as executable software specifications to
automatically verify that the software behaves as intended.
A user story
With Cucumber, template
this means often
writing uses the following
Given-When-Then scenarios to illustrate the examples.
These specifications (called scenarios) are then executed regularly by a tool like Cucumber.
type of format:
As a <role>,
Teams run these I wantthroughout
specifications <feature> development
so that <reason>.
to get immediate feedback about how
much isExamples
yet to be done, and stories:
of user whether the software meets the user’s requirements. The
executable specifications tell them what needs to be implemented. Cucumber provides
informationAs in awhich
user,parts
I want tospecification
of the upload photos so that I can
are implemented correctly, and which parts are
incomplete share photos with others.
or defective.
As an
This technique administrator,
is called Outside-in Ibecause
want to approve photos
programmers typically start with the functionality
before
that is closest to thethey are user
user (the posted so that
interface, I can
which make
is on sure of the system) and
the outside
theytowards
gradually work are appropriate.
the guts of the system (business logic, persistence, messaging and so
on) as they As
discover
a user,more
I canof what needsfolders
indicate to be implemented.
not to backup
This meansso that myfeatures
Cucumber backupshould
drivebeisn't filled
written up with
before the code implementing
things I don't need saved
the feature.
 Executable specifications

When you do BDD/Specification by Example and Outside-in, regression tests

are a by-product of those activities.
TestingA isn’t
user story template
the activity often uses the following
itself.
type of format:
These executable specifications also work as automated regression tests which
As a <role>, I want <feature> so that <reason>.
reduces costly and time-consuming manual regression testing.
Examples of user stories:
Testers can
As use theirI want
a user, time for more valuable
to upload photos so things,
that I like
can exploratory testing.
share photos with
Keeping specifications, others. tests and documentation in a single place
regression
reduces the
As overhead of keeping
an administrator, multiple
I want documents
to approve photos in sync - the Cucumber
scenarios before
work asthey are posted
a shared sourcesoofthat I can
truth for make sureand IT.
business
they are appropriate.
Real value is actually the shared understanding we get at the beginning!
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 Gherkin
Gherkin is plain-text language with a little extra structure designed to be easy to learn by non-
programmers. It allows concise description of examples to illustrate business rules in most real-world
domains. One of the big advantage is that it clearly highlights the intent of the example/test.
A user
Follow these basicstory template
steps to begin usingoften uses
BDD and the syntax:
Gherkin following
type of format:
1. Start with your user stories.
As aAsteam,
a <role>, I want
go through your<feature>
user storiesso and
thatwrite
<reason>.
BDD scenarios using the keywords GIVEN,
WHEN, and THEN
Examples of user (AND, BUT can be used as well)
stories:
GIVEN is your setup; for example, “GIVEN the credit card is valid”
WHEN As ais user, I want
your action; to upload
for example, “WHEN photos so that
I request $50” I can
THEN is your
share assertion;
photos for example,
with others.“THEN the ATM should dispense $50”
Capture the BDD scenarios in a location that is public for everyone to see.
2. AutomateAs anBDD
your administrator,
scenarios. I want to approve photos
Firstbefore
executionthey areasposted
will fail the featuresois that
not yetI implemented
can make sure
Automation
they clearly
are requires development skill.
appropriate.
3. Implement the features
4. As a user,
Run the automated BDDI can indicate
scenarios to showfolders not
the feature to backup
is completed
5. Repeat so that my backup drive isn't filled up with
things I don't need saved
 Gherkin example
Here is a sample of an actual Tamedia Gherkin document:
Feature: User obtained a voucher and wants to redeem it
Scenario: Voucher
A user link active
story template often uses the following
Given on payment page
type of
When nothing format:
done
Then redeemAs a <role>,
voucher I want
link is visible<feature> so that <reason>.
Scenario: Voucher link clicked - turns inactive
Examples
Given on of user stories:
payment page
When redeem Asvoucher
a user,link
I want to upload photos so that I can
is clicked
Then activation button
share remains
photos inactive
with others.
As an administrator, I want to approve photos
before they are posted so that I can make sure
they are appropriate.
As a user, I can indicate folders not to backup
so that my backup drive isn't filled up with
things I don't need saved
 Gherkin syntax
.

. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Software design
.

. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Costs per defects
.

. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Mission
. Delivered work passes all tests and is free of any defects
and is operationally functional as defined!
 Mission
. Delivered work passes all tests and is free of any defects
and is operationally functional as defined!
 Developers vs testers
.

It is a common mistake to think that devs and testers are not on same team and mission
. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Developers vs testers
.

It is a common mistake to think that devs and testers are not on same team and mission
. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Developers vs testers
.

It is a common mistake to think that devs and testers are not on same team and mission
. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Developers vs testers
.

It is a common mistake to think that devs and testers are not on same team and mission
. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 Ideal software testing pyramid
.

. Feature

. Scenario
.

. Given, When, Then, And, But

.

. Scenario Outline, Examples

 QA Team
Test manager

Test engineer

Tester
 Test manager
Test manager

Test engineer

Tester
 Test manager
Test manager

Test engineer

Tester
 Test engineer
Test manager

Test engineer

Tester
 Test engineer
Test manager

Test engineer

Tester
 Test engineer
Test manager

Test engineer

Tester
 Test types
Test manager

Test engineer

Tester
 Unit tests
Test manager

Test engineer

Tester
 Unit tests vs integration tests
Test manager

Test engineer

Tester
 Regression test
Test manager

Test engineer

Tester
 Regression test
Test manager

Test engineer

Tester
 Acceptance tests
Test manager

Test engineer

Tester