BDD: The unit test of the product owner

2,158 views

Published on

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

This is a variation on the talk I gave at Agile Australia, that I delivered at the Sydney Agile meetup on July 15 2014.

Published in: Technology
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,158
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
65
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide

BDD: The unit test of the product owner

  1. 1. BDD The unit test of the product owner
  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   tes*ng BA Developer Tester Many teams build features like this… “a shared understanding”
  74. 74. Story bug  reports Working   code boring   manual   tes*ng BA Developer Tester Many teams build features like this… “a shared understanding”
  75. 75. Story bug  reports Working   code boring   manual   tes*ng 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  tes*ng,   usability  tes*ng... 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  star*ng  point  for  manual  tests Illustrates  delivered  features
  96. 96. Living Documentation A  star*ng  point  for  manual  tests Illustrates  delivered  features Progress  repor*ng
  97. 97. Living Documentation A  star*ng  point  for  manual  tests Illustrates  delivered  features Func*onal  and  technical  documenta*on Progress  repor*ng
  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  specifica;ons” 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  specifica;ons” 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  specifica;ons” 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  specifica;ons  for  the  code “building the software right”
  132. 132. Then  write  low-­‐level  specifica;ons  for  the  code “building the software right”
  133. 133. “building the software right”
  134. 134. “building the software right” These  low  level  specifica;ons  become  technical   documenta;on  for  your  APIs
  135. 135. “Every class is an API for someone”
  136. 136. BDD  requires  high  business  engagement  and  collabora;on   Adoption challenges
  137. 137. BDD  works  best  in  an  Agile  or  Itera;ve  context   Adoption challenges
  138. 138. BDD  does  not  work  well  in  a  silo   Adoption challenges
  139. 139. 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  
  140. 140. BDD Gotchas 1 2 3 4
  141. 141. BDD Gotchas 1 2 3 4 An;-­‐paNern  1   The  business  analyst  writes  the  scenarios  and  then  gives   them  to  the  other  team  members.
  142. 142. 1 2 3 4 BDD Gotchas
  143. 143. 1 2 3 4 BDD Gotchas An;-­‐paNern  2   The  tester  writes  the  scenarios  at  the  end   to  implement  an  automated  test  suite.
  144. 144. 1 2 3 4 5 BDD Gotchas
  145. 145. 1 2 3 4 5 BDD Gotchas An;-­‐paNern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  146. 146. 1 2 3 4 5 BDD Gotchas An;-­‐paNern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  147. 147. 1 2 3 4 5 BDD Gotchas
  148. 148. 1 2 3 4 5 BDD Gotchas An;-­‐paNern  4   The  scenarios  are  too  UI-­‐centric  or  detail-­‐focused,  and  neglect  to  express   the  core  business  value.
  149. 149. In conclusion… It’s  behaviour  all  the  way  down
  150. 150. Want to learn more?
  151. 151. Want to learn more?
  152. 152. Want to learn more? http://jbehave.org/
  153. 153. Want to learn more? http://thucydides.info/ http://jbehave.org/
  154. 154. Want to learn more? http://thucydides.info/ https://code.google.com/p/spock/ http://jbehave.org/
  155. 155. Want to learn more? http://www.wakaleo.com
  156. 156. Want to learn more? Discount  code:   MEETUP2014 http://www.wakaleo.com
  157. 157. Thank You John Ferguson Smart john.smart@wakaleo.com wakaleo http://www.wakaleo.com

×