bdd in action - building software that matters
TRANSCRIPT
BDD
Hunting out value Automated Acceptance Criteria
Collaboration
Building the right software
So what is this BDD thing?
BDD
Hunting out value Automated Acceptance Criteria
API and code design
Collaboration
Building the right software
So what is this BDD thing?
BDD
Hunting out value Automated Acceptance Criteria
API and code design
Collaboration
Building the software right
Building the right software
So what is this BDD thing?
BDD
Hunting out value Automated Acceptance Criteria
API and code design
Collaboration
Building the software right
Building the right software
Living Documentation
So what is this BDD thing?
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
•Specifica8ons are elaborated collabora8vely •Specifica8ons use a common language •Executable specifica8ons provide fast feedback
BDD in a nutshell
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Solves the wrong problem well
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Solves the wrong problem well
Solves the right problem poorly
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Buggy and useless
Solves the wrong problem well
Solves the right problem poorly
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Buggy and useless
Slow to change
Solves the wrong problem well
Solves the right problem poorly
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Buggy and useless
Hard to maintain
Slow to change
Solves the wrong problem well
Solves the right problem poorly
“software that matters”
Building the thing right
Building the right thing
Wha
t
How
Mis
alig
ned
requ
irem
ents
Poor craftsmanship
Buggy and useless
Hard to maintain
Slow to change
Does what the business needs Reliable Easy to maintain
Solves the wrong problem well
Solves the right problem poorly
You don’t know what you don’t knowUnderstanding of what needs to be
delivered
Time
Requirementsphase done
AnalysisPhase done
You don’t know what you don’t knowUnderstanding of what needs to be
delivered
Time
Requirementsphase done
AnalysisPhase done
You don’t know what you don’t knowUnderstanding of what needs to be
delivered
Time
Requirementsphase done
AnalysisPhase done
•Our ignorance decreases over 8me • It does not decrease at a linear rate • It does not always decrease in a predictable way
Business Goal
Business Goal
Business Goal
“software that matters”
We start with a business goal
“Increase *cket sales by 5% over the next year by encouraging travelers to fly with Flying High
rather than with a rival company.”
Business Goal
Business Goal
Business Goal
“software that matters”
What features will enable us to deliver this goal?
FeaturesFeaturesFeatures
Business Goal
Business Goal
Business Goal
“software that matters”
What features will enable us to deliver this goal?
FeaturesFeaturesFeaturesEarn Frequent Flyer points from flights
Business Goal
Business Goal
Business Goal
“software that matters”
What features will enable us to deliver this goal?
FeaturesFeaturesFeaturesEarn Frequent Flyer points from flights
Earn Frequent Flyer points from purchases
Business Goal
Business Goal
Business Goal
“software that matters”
What features will enable us to deliver this goal?
FeaturesFeaturesFeaturesEarn Frequent Flyer points from flights
Earn Frequent Flyer points from purchases
View Frequent Flyer account balance online
Business Goal
Business Goal
Business Goal
“software that matters”
We use conversa8ons around examples to build up our understanding of these features
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Business Goal
Business Goal
Business Goal
“software that matters”
We use conversa8ons around examples to build up our understanding of these features
FeaturesFeaturesFeatures FeaturesFeaturesExamples
“A new Frequent Flyer member starts off with Bronze status”
Business Goal
Business Goal
Business Goal
“software that matters”
We use conversa8ons around examples to build up our understanding of these features
FeaturesFeaturesFeatures FeaturesFeaturesExamples
“A new Frequent Flyer member starts off with Bronze status”
“If she earns 300 points, she becomes a Silver Frequent Flyer member”
“Using examples”
•Explore requirements •Discover what we don’t know •Clarify ambigui8es • Iden8fy assump8ons and misunderstandings
“Using examples”“A new Frequent Flyer member starts off with Bronze status”
•Explore requirements •Discover what we don’t know •Clarify ambigui8es • Iden8fy assump8ons and misunderstandings
“Using examples”“A new Frequent Flyer member starts off with Bronze status”
“If she earns 300 points, she becomes a Silver Frequent Flyer member”
•Explore requirements •Discover what we don’t know •Clarify ambigui8es • Iden8fy assump8ons and misunderstandings
“Using examples”“A new Frequent Flyer member starts off with Bronze status”
“If she earns 300 points, she becomes a Silver Frequent Flyer member”
“If I ask for the details about the flight FH-‐102, I should see that it is a Sydney to Hong Kong flight that leaves at 11:55pm ”
•Explore requirements •Discover what we don’t know •Clarify ambigui8es • Iden8fy assump8ons and misunderstandings
“Having the conversa/on is more important than
recording the conversa/on is more important than
automa/ng the conversa/on” -‐ Liz Keogh
“a shared understanding”
Story
Working code
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
Working code boring
manual tes5ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
bug reports
Working code boring
manual tes5ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
bug reports
Working code boring
manual tes5ng
WASTEBA
Developer
Tester
Many teams build features like this…
“a shared understanding”
…but a little cooperation goes a long way…
StoryExamplesAutomated acceptance criteria
“a shared understanding”
…but a little cooperation goes a long way…
Shared understanding
StoryExamplesAutomated acceptance criteria
“a shared understanding”
…but a little cooperation goes a long way…
Working code and
Working Automated Acceptance Tests
Shared understanding
StoryExamplesAutomated acceptance criteria
“a shared understanding”
…but a little cooperation goes a long way…
Working code and
Working Automated Acceptance Tests Exploratory tes5ng,
usability tes5ng...
Shared understanding
StoryExamplesAutomated acceptance criteria
“a shared understanding”
We call this “The Three Amigos”
BA and/or product owner
Tester Developer Automatable Acceptance Criteria
Shared understanding
“a shared understanding”
Living Documentation
A star5ng point for manual tests
Illustrates delivered features
Progress repor5ng
Living Documentation
A star5ng point for manual tests
Illustrates delivered features
Func5onal and technical documenta5on
Progress repor5ng
Feature Coverage
What stories are defined for this feature?
How many stories have automated acceptance criteria?
Feature Coverage
What stories are defined for this feature?
How many stories have automated acceptance criteria?
What acceptance criteria have been automated?
Business Goal
Business Goal
Business Goal
We can automate these examples in the form of “executable specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
“building the software right”
Business Goal
Business Goal
Business Goal
We can automate these examples in the form of “executable specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
“building the software right”
Business Goal
Business Goal
Business Goal
We can automate these examples in the form of “executable specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
“building the software right”
Business Goal
Business Goal
Business Goal
We use low-‐level BDD or TDD tools to define the behavior of components, classes etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
“building the software right”
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Business Goal
Business Goal
Business Goal
We use low-‐level BDD or TDD tools to define the behavior of components, classes etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
spockRSpec
“building the software right”
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Business Goal
Business Goal
Business Goal
We use low-‐level BDD or TDD tools to define the behavior of components, classes etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
spockRSpec
“building the software right”
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Low level specifications
“building the software right”
These low level specifica8ons become technical documenta8on for your APIs
BDD Gotchas
12
3
4An8-‐paQern 1 The business analyst writes the scenarios and then gives them to the other team members.
12
3
4
BDD Gotchas
An8-‐paQern 2 The tester writes the scenarios at the end to implement an automated test suite.
1
2
3
45
BDD Gotchas
An8-‐paQern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a?erwards.
1
2
3
45
BDD Gotchas
An8-‐paQern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a?erwards.
1
2
3
45
BDD Gotchas
An8-‐paQern 4 The scenarios are too UI-‐centric or detail-‐focused, and neglect to express the core business value.
Adoption challenges
Skill and prac,ce required: •Wri,ng good scenarios takes prac,ce •Poorly wri:en tests can lead to higher test-‐maintenance costs •Need to treat test automa,on code like produc,on code
Thank You
John Ferguson Smart
wakaleo
http://www.wakaleo.com