bdd: the unit test of the product owner
TRANSCRIPT
BDD
The unit test of the product owner
John Ferguson Smart
Consultant Trainer Mentor Author Speaker Coder
John Ferguson Smart
Consultant Trainer Mentor Author Speaker Coder
John Ferguson Smart
Consultant Trainer Mentor Author Speaker Coder
John Ferguson Smart
Consultant Trainer Mentor Author Speaker Coder
So what is this BDD thing?
Using examples
So what is this BDD thing?
Using examples
a shared understanding
So what is this BDD thing?
Using examples
a shared understanding
software that matters
So what is this BDD thing?
BDD
So what is this BDD thing?
BDDCollaboration
So what is this BDD thing?
BDD
Hunting out value
Collaboration
So what is this BDD thing?
BDD
Hunting out value
Collaboration
Building the right software
So what is this BDD thing?
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
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
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”
“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
“Using examples”
We express the examples in a structured format using simple English phrases
“Using examples”
We express the examples in a structured format using simple English phrases
“Using examples”
We express the examples in a structured format using simple English phrases
“Using examples”
We express the examples in a structured format using simple English phrases
“Using examples”
The automated acceptance criteria guide the development process
“Using examples”
The automated acceptance criteria guide the development process
“Using examples”
The automated acceptance criteria guide the development process
“a shared understanding”
“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”
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
Working code
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
Working code boring
manual tes*ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
bug reports
Working code boring
manual tes*ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
Story
bug reports
Working code boring
manual tes*ng
WASTEBA
Developer
Tester
Many teams build features like this…
“a shared understanding”
…but a little cooperation goes a long way…
Story
“a shared understanding”
…but a little cooperation goes a long way…
Story
“a shared understanding”
…but a little cooperation goes a long way…
Story
“a shared understanding”
…but a little cooperation goes a long way…
Story
“a shared understanding”
…but a little cooperation goes a long way…
StoryExamples
“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 tes*ng,
usability tes*ng...
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”
We call this “The Three Amigos”
“a shared understanding”
We call this “The Three Amigos”
“a shared understanding”
We call this “The Three Amigos”
“a shared understanding”
We call this “The Three Amigos”
“a shared understanding”
We call this “The Three Amigos”
“a shared understanding”
“Automation without collaboration is empty”
Living Documentation
Living Documentation
Living Documentation
Illustrates delivered features
Living Documentation
A star*ng point for manual tests
Illustrates delivered features
Living Documentation
A star*ng point for manual tests
Illustrates delivered features
Progress repor*ng
Living Documentation
A star*ng point for manual tests
Illustrates delivered features
Func*onal and technical documenta*on
Progress repor*ng
Automated test results tell us…
Automated test results tell us…
How many tests passed
Automated test results tell us…
How many failed
How many tests passed
Automated test results tell us…
How many failed
How many tests passed
How many weren’t run
Automated test results tell us…
Automated test results tell us…
What tests exist for a given feature
Automated test results tell us…
What tests exist for a given feature
How stable the feature is
Automated test results tell us…
Automated test results tell us…
How a feature was tested
Automated test results tell us…
Automated test results tell us…
What a feature looks like
Automated test results tell us…
Automated test results tell us…
What a feature looks like
Automated test results tell us…
What a feature looks like
Test results do not tell us what was not tested
Feature Coverage
Feature Coverage
What stories are defined for this feature?
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?
“Living Documentation completes the circle”
Business Goal
Business Goal
Business Goal
We can automate these examples in the form of “executable specifica;ons”
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 specifica;ons”
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 specifica;ons”
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”
Acceptance criteria tell us what we need to build…
“building the software right”
“building the software right”
What would we like the API to look like?
“building the software right”
What would we like the API to look like?
“building the software right”
What would we like the API to look like?
“building the software right”
“building the software right”
Then write low-‐level specifica;ons for the code
“building the software right”
Then write low-‐level specifica;ons for the code
“building the software right”
“building the software right”
“building the software right”
These low level specifica;ons become technical documenta;on for your APIs
“Every class is an API for someone”
BDD requires high business engagement and collabora;on
Adoption challenges
BDD works best in an Agile or Itera;ve context
Adoption challenges
BDD does not work well in a silo
Adoption challenges
Adoption challenges
Skill and prac;ce required: •Wri;ng good scenarios takes prac;ce •Poorly wriNen tests can lead to higher test-‐maintenance costs •Need to treat test automa;on code like produc;on code
BDD Gotchas
12
3
4
BDD Gotchas
12
3
4An;-‐paNern 1 The business analyst writes the scenarios and then gives them to the other team members.
12
3
4
BDD Gotchas
12
3
4
BDD Gotchas
An;-‐paNern 2 The tester writes the scenarios at the end to implement an automated test suite.
1
2
3
45
BDD Gotchas
1
2
3
45
BDD Gotchas
An;-‐paNern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a?erwards.
1
2
3
45
BDD Gotchas
An;-‐paNern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a?erwards.
1
2
3
45
BDD Gotchas
1
2
3
45
BDD Gotchas
An;-‐paNern 4 The scenarios are too UI-‐centric or detail-‐focused, and neglect to express the core business value.
In conclusion…
It’s behaviour all the way down
Want to learn more?
Want to learn more?
Want to learn more?
http://jbehave.org/
Want to learn more?
http://thucydides.info/
http://jbehave.org/
Want to learn more?
http://thucydides.info/
https://code.google.com/p/spock/
http://jbehave.org/
Thank You
John Ferguson Smart
wakaleo
http://www.wakaleo.com