BDD
in action
Building software that matters
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?
BDD
Collaboration
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 ...
BDD
Hunting out value Automated Acceptance
Criteria
API and code design
Collaboration
Building the software right
Building...
BDD
Hunting out value Automated Acceptance
Criteria
API and code design
Collaboration
Building the software right
Building...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The ...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenari...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
“software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmansh...
You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase...
You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase...
You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase...
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	
...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
What	
  features	
  will	
  enable	
  us	
  to	
  delive...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
What	
  features	
  will	
  enable	
  us	
  to	
  delive...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
What	
  features	
  will	
  enable	
  us	
  to	
  delive...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
What	
  features	
  will	
  enable	
  us	
  to	
  delive...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
We	
  use	
  conversa8ons	
  around	
  examples	
  to	
 ...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
We	
  use	
  conversa8ons	
  around	
  examples	
  to	
 ...
Business
Goal
Business
Goal
Business
Goal
“software that matters”
We	
  use	
  conversa8ons	
  around	
  examples	
  to	
 ...
“Using examples”
“Using examples”
•Explore	
  requirements	
  
•Discover	
  what	
  we	
  don’t	
  know	
  
•Clarify	
  ambigui8es	
  
•Ide...
“Using examples”
“A	
  new	
  Frequent	
  Flyer	
  member	
  
starts	
  off	
  with	
  Bronze	
  status”
•Explore	
  requir...
“Using examples”
“A	
  new	
  Frequent	
  Flyer	
  member	
  
starts	
  off	
  with	
  Bronze	
  status”
“If	
  she	
  earn...
“Using examples”
“A	
  new	
  Frequent	
  Flyer	
  member	
  
starts	
  off	
  with	
  Bronze	
  status”
“If	
  she	
  earn...
“Using examples”
We	
  express	
  the	
  examples	
  in	
  a	
  structured	
  
format	
  using	
  simple	
  English	
  phr...
“Using examples”
We	
  express	
  the	
  examples	
  in	
  a	
  structured	
  
format	
  using	
  simple	
  English	
  phr...
“Using examples”
We	
  express	
  the	
  examples	
  in	
  a	
  structured	
  
format	
  using	
  simple	
  English	
  phr...
“Using examples”
We	
  express	
  the	
  examples	
  in	
  a	
  structured	
  
format	
  using	
  simple	
  English	
  phr...
“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	
  mo...
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	
  
tes5ng
BA
Developer
Tester
Many teams build features like this…
“a shared und...
Story
bug	
  reports
Working	
  
code boring	
  
manual	
  
tes5ng
BA
Developer
Tester
Many teams build features like this...
Story
bug	
  reports
Working	
  
code boring	
  
manual	
  
tes5ng
WASTE
BA
Developer
Tester
Many teams build features lik...
…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…
Story
Examples
“a shared understanding”
…but a little cooperation goes a long way…
Story
Examples
Automated	
  
acceptance	
  
criteria
“a shared understanding”
…but a little cooperation goes a long way…
Shared	
  
understanding
Story
Examples
Automated	
  
acceptance	
  
criteria
“...
…but a little cooperation goes a long way…
Working	
  code	
  	
  
and	
  	
  
Working	
  Automated	
  
Acceptance	
  Test...
…but a little cooperation goes a long way…
Working	
  code	
  	
  
and	
  	
  
Working	
  Automated	
  
Acceptance	
  Test...
We call this “The Three Amigos”
BA	
  and/or	
  product	
  owner
Tester Developer Automatable	
  
Acceptance	
  
Criteria
...
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	
  star5ng	
  point	
  for	
  manual	
  tests
Illustrates	
  delivered	
  features
Living Documentation
A	
  star5ng	
  point	
  for	
  manual	
  tests
Illustrates	
  delivered	
  features
Progress	
  repo...
Living Documentation
A	
  star5ng	
  point	
  for	
  manual	
  tests
Illustrates	
  delivered	
  features
Func5onal	
  and...
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	
 ...
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	...
Feature Coverage
What	
  stories	
  are	
  defined	
  
for	
  this	
  feature?
How	
  many	
  stories	
  have	
  automated	...
“Living Documentation
completes the circle”
Business
Goal
Business
Goal
Business
Goal
We	
  can	
  automate	
  these	
  examples	
  in	
  the	
  form	
  of	
  
“execu...
Business
Goal
Business
Goal
Business
Goal
We	
  can	
  automate	
  these	
  examples	
  in	
  the	
  form	
  of	
  
“execu...
Business
Goal
Business
Goal
Business
Goal
We	
  can	
  automate	
  these	
  examples	
  in	
  the	
  form	
  of	
  
“execu...
Business
Goal
Business
Goal
Business
Goal
We	
  use	
  low-­‐level	
  BDD	
  or	
  TDD	
  tools	
  to	
  define	
  the	
  
...
Business
Goal
Business
Goal
Business
Goal
We	
  use	
  low-­‐level	
  BDD	
  or	
  TDD	
  tools	
  to	
  define	
  the	
  
...
Business
Goal
Business
Goal
Business
Goal
We	
  use	
  low-­‐level	
  BDD	
  or	
  TDD	
  tools	
  to	
  define	
  the	
  
...
“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	
  specifica8ons	
  for	
  the	
  code
“building the software right”
Then	
  write	
  low-­‐level	
  specifica8ons	
  for	
  the	
  code
“building the software right”
“building the software right”
“building the software right”
These	
  low	
  level	
  specifica8ons	
  become	
  technical	
  
documenta8on	
  for	
  your...
“Every class is an API for
someone”
BDD Gotchas
1
2
3
4
BDD Gotchas
1
2
3
4
An8-­‐paQern	
  1	
  
The	
  business	
  analyst	
  writes	
  the	
  scenarios	
  and	
  then	
  gives...
1
2
3
4
BDD Gotchas
1
2
3
4
BDD Gotchas
An8-­‐paQern	
  2	
  
The	
  tester	
  writes	
  the	
  scenarios	
  at	
  the	
  end	
  
to	
  implem...
1
2
3
4
5
BDD Gotchas
1
2
3
4
5
BDD Gotchas
An8-­‐paQern	
  3	
  
The	
  “Three	
  Amigos”	
  sessions	
  don’t	
  result	
  in	
  usable	
  sce...
1
2
3
4
5
BDD Gotchas
An8-­‐paQern	
  3	
  
The	
  “Three	
  Amigos”	
  sessions	
  don’t	
  result	
  in	
  usable	
  sce...
1
2
3
4
5
BDD Gotchas
1
2
3
4
5
BDD Gotchas
An8-­‐paQern	
  4	
  
The	
  scenarios	
  are	
  too	
  UI-­‐centric	
  or	
  detail-­‐focused,	
  a...
42
Benefits of BDD
•Focus	
  effort	
  
•Reduce	
  waste	
  and	
  misaligned	
  requirements
43
Benefits of BDD
Deliver	
  more	
  valuable	
  soYware
44
Benefits of BDD
Make	
  changes	
  safely
45
Benefits of BDD
Faster	
  and	
  more	
  reliable	
  releases
46
Benefits of BDD
Reduced	
  maintenance	
  costs
BDD	
  requires	
  high	
  business	
  engagement	
  and	
  collabora8on	
  
Adoption challenges
BDD	
  works	
  best	
  in	
  an	
  Agile	
  or	
  Itera8ve	
  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	...
In conclusion…
It’s	
  behaviour	
  all	
  the	
  way	
  down
Want to learn more?
Want to learn more?
Want to learn more?
http://thucydides.info/
Want to learn more?
http://thucydides.info/
https://code.google.com/p/spock/
Thank You
John Ferguson Smart
john.smart@wakaleo.com
wakaleo
http://www.wakaleo.com
Upcoming SlideShare
Loading in...5
×

BDD in Action - building software that matters

8,050

Published on

Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.

Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them

Published in: Technology, Business
3 Comments
45 Likes
Statistics
Notes
No Downloads
Views
Total Views
8,050
On Slideshare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
260
Comments
3
Likes
45
Embeds 0
No embeds

No notes for slide

BDD in Action - building software that matters

  1. 1. BDD
in action Building software that matters
  2. 2. John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  3. 3. John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  4. 4. John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  5. 5. John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  6. 6. So what is this BDD thing?
  7. 7. Using examples So what is this BDD thing?
  8. 8. Using examples a shared understanding So what is this BDD thing?
  9. 9. Using examples a shared understanding software that matters So what is this BDD thing?
  10. 10. BDD So what is this BDD thing?
  11. 11. BDD Collaboration So what is this BDD thing?
  12. 12. BDD Hunting out value Collaboration So what is this BDD thing?
  13. 13. BDD Hunting out value Collaboration Building the right software So what is this BDD thing?
  14. 14. BDD Hunting out value Automated Acceptance Criteria Collaboration Building the right software So what is this BDD thing?
  15. 15. BDD Hunting out value Automated Acceptance Criteria API and code design Collaboration Building the right software So what is this BDD thing?
  16. 16. 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?
  17. 17. 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?
  18. 18. The business owner tells the business analyst what he wants 1 2 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
  19. 19. The business owner tells the business analyst what he wants 1 2 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
  20. 20. The business owner tells the business analyst what he wants 1 2 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
  21. 21. The business owner tells the business analyst what he wants 1 2 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
  22. 22. The business owner tells the business analyst what he wants 1 2 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
  23. 23. The business owner tells the business analyst what he wants 1 2 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
  24. 24. The business owner tells the business analyst what he wants 1 2 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
  25. 25. The business owner tells the business analyst what he wants 1 2 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
  26. 26. The business owner tells the business analyst what he wants 1 2 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
  27. 27. The business owner tells the business analyst what he wants 1 2 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
  28. 28. The business owner tells the business analyst what he wants 1 2 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship
  37. 37. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Solves the wrong problem well
  38. 38. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Solves the wrong problem well Solves the right problem poorly
  39. 39. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Solves the wrong problem well Solves the right problem poorly
  40. 40. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Slow to change Solves the wrong problem well Solves the right problem poorly
  41. 41. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Hard to maintain Slow to change Solves the wrong problem well Solves the right problem poorly
  42. 42. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements 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
  43. 43. You don’t know what you don’t know Understanding of what needs to be delivered Time
  44. 44. You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done
  45. 45. You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done
  46. 46. You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done •Our  ignorance  decreases  over  8me   •It  does  not  decrease  at  a  linear  rate   •It  does  not  always  decrease  in  a  predictable  way
  47. 47. Business Goal Business Goal Business Goal “software that matters” We  start  with  a  business  goal
  48. 48. 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.”
  49. 49. Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures
  50. 50. Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights
  51. 51. Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights Earn  Frequent  Flyer  points  from  purchases
  52. 52. Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights Earn  Frequent  Flyer  points  from  purchases View  Frequent  Flyer  account  balance  online
  53. 53. Business Goal Business Goal Business Goal “software that matters” We  use  conversa8ons  around  examples  to  build  up  our   understanding  of  these  features   FeaturesFeaturesFeatures FeaturesFeaturesExamples
  54. 54. 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”
  55. 55. 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”
  56. 56. “Using examples”
  57. 57. “Using examples” •Explore  requirements   •Discover  what  we  don’t  know   •Clarify  ambigui8es   •Iden8fy  assump8ons  and  misunderstandings  
  58. 58. “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  
  59. 59. “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  
  60. 60. “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  
  61. 61. “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  62. 62. “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  63. 63. “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  64. 64. “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  65. 65. “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  66. 66. “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  67. 67. “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  68. 68. “a shared understanding”
  69. 69. “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”
  70. 70. BA Developer Tester Many teams build features like this… “a shared understanding”
  71. 71. Story BA Developer Tester Many teams build features like this… “a shared understanding”
  72. 72. Story Working   code BA Developer Tester Many teams build features like this… “a shared understanding”
  73. 73. Story Working   code boring   manual   tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”
  74. 74. Story bug  reports Working   code boring   manual   tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”
  75. 75. Story bug  reports Working   code boring   manual   tes5ng WASTE BA Developer Tester Many teams build features like this… “a shared understanding”
  76. 76. …but a little cooperation goes a long way… Story “a shared understanding”
  77. 77. …but a little cooperation goes a long way… Story “a shared understanding”
  78. 78. …but a little cooperation goes a long way… Story “a shared understanding”
  79. 79. …but a little cooperation goes a long way… Story “a shared understanding”
  80. 80. …but a little cooperation goes a long way… Story Examples “a shared understanding”
  81. 81. …but a little cooperation goes a long way… Story Examples Automated   acceptance   criteria “a shared understanding”
  82. 82. …but a little cooperation goes a long way… Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  83. 83. …but a little cooperation goes a long way… Working  code     and     Working  Automated   Acceptance  Tests Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  84. 84. …but a little cooperation goes a long way… Working  code     and     Working  Automated   Acceptance  Tests Exploratory  tes5ng,   usability  tes5ng... Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  85. 85. We call this “The Three Amigos” BA  and/or  product  owner Tester Developer Automatable   Acceptance   Criteria Shared   understanding “a shared understanding”
  86. 86. We call this “The Three Amigos” “a shared understanding”
  87. 87. We call this “The Three Amigos” “a shared understanding”
  88. 88. We call this “The Three Amigos” “a shared understanding”
  89. 89. We call this “The Three Amigos” “a shared understanding”
  90. 90. We call this “The Three Amigos” “a shared understanding”
  91. 91. “Automation without collaboration is empty”
  92. 92. Living Documentation
  93. 93. Living Documentation
  94. 94. Living Documentation Illustrates  delivered  features
  95. 95. Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features
  96. 96. Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features Progress  repor5ng
  97. 97. Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features Func5onal  and  technical  documenta5on Progress  repor5ng
  98. 98. Automated test results tell us…
  99. 99. Automated test results tell us… How  many   tests  passed
  100. 100. Automated test results tell us… How  many  failed How  many   tests  passed
  101. 101. Automated test results tell us… How  many  failed How  many   tests  passed How  many  weren’t  run
  102. 102. Automated test results tell us…
  103. 103. Automated test results tell us… What  tests  exist  for   a  given  feature
  104. 104. Automated test results tell us… What  tests  exist  for   a  given  feature How  stable  the  feature  is
  105. 105. Automated test results tell us…
  106. 106. Automated test results tell us… How  a  feature  was   tested
  107. 107. Automated test results tell us…
  108. 108. Automated test results tell us… What  a  feature  looks  like
  109. 109. Automated test results tell us…
  110. 110. Automated test results tell us… What  a  feature  looks  like
  111. 111. Automated test results tell us… What  a  feature  looks  like
  112. 112. Test results do not tell us what was not tested
  113. 113. Feature Coverage
  114. 114. Feature Coverage What  stories  are  defined   for  this  feature?
  115. 115. Feature Coverage What  stories  are  defined   for  this  feature? How  many  stories  have  automated   acceptance  criteria?
  116. 116. Feature Coverage What  stories  are  defined   for  this  feature? How  many  stories  have  automated   acceptance  criteria? What  acceptance  criteria  have   been  automated?
  117. 117. “Living Documentation completes the circle”
  118. 118. Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  119. 119. Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  120. 120. Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  121. 121. Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  122. 122. Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications spock RSpec “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  123. 123. Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications spock RSpec “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  124. 124. “building the software right”
  125. 125. Acceptance  criteria  tell  us  what  we  need  to  build… “building the software right”
  126. 126. “building the software right”
  127. 127. What  would  we  like  the  API  to  look  like? “building the software right”
  128. 128. What  would  we  like  the  API  to  look  like? “building the software right”
  129. 129. What  would  we  like  the  API  to  look  like? “building the software right”
  130. 130. “building the software right”
  131. 131. Then  write  low-­‐level  specifica8ons  for  the  code “building the software right”
  132. 132. Then  write  low-­‐level  specifica8ons  for  the  code “building the software right”
  133. 133. “building the software right”
  134. 134. “building the software right” These  low  level  specifica8ons  become  technical   documenta8on  for  your  APIs
  135. 135. “Every class is an API for someone”
  136. 136. BDD Gotchas 1 2 3 4
  137. 137. BDD Gotchas 1 2 3 4 An8-­‐paQern  1   The  business  analyst  writes  the  scenarios  and  then  gives   them  to  the  other  team  members.
  138. 138. 1 2 3 4 BDD Gotchas
  139. 139. 1 2 3 4 BDD Gotchas An8-­‐paQern  2   The  tester  writes  the  scenarios  at  the  end   to  implement  an  automated  test  suite.
  140. 140. 1 2 3 4 5 BDD Gotchas
  141. 141. 1 2 3 4 5 BDD Gotchas An8-­‐paQern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  142. 142. 1 2 3 4 5 BDD Gotchas An8-­‐paQern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  143. 143. 1 2 3 4 5 BDD Gotchas
  144. 144. 1 2 3 4 5 BDD Gotchas An8-­‐paQern  4   The  scenarios  are  too  UI-­‐centric  or  detail-­‐focused,  and  neglect  to  express   the  core  business  value.
  145. 145. 42 Benefits of BDD •Focus  effort   •Reduce  waste  and  misaligned  requirements
  146. 146. 43 Benefits of BDD Deliver  more  valuable  soYware
  147. 147. 44 Benefits of BDD Make  changes  safely
  148. 148. 45 Benefits of BDD Faster  and  more  reliable  releases
  149. 149. 46 Benefits of BDD Reduced  maintenance  costs
  150. 150. BDD  requires  high  business  engagement  and  collabora8on   Adoption challenges
  151. 151. BDD  works  best  in  an  Agile  or  Itera8ve  context   Adoption challenges
  152. 152. BDD  does  not  work  well  in  a  silo   Adoption challenges
  153. 153. 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  
  154. 154. In conclusion… It’s  behaviour  all  the  way  down
  155. 155. Want to learn more?
  156. 156. Want to learn more?
  157. 157. Want to learn more? http://thucydides.info/
  158. 158. Want to learn more? http://thucydides.info/ https://code.google.com/p/spock/
  159. 159. Thank You John Ferguson Smart john.smart@wakaleo.com wakaleo http://www.wakaleo.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×