BDD in Action - building software that matters

15,860 views

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
72 Likes
Statistics
Notes
No Downloads
Views
Total views
15,860
On SlideShare
0
From Embeds
0
Number of Embeds
6,565
Actions
Shares
0
Downloads
536
Comments
3
Likes
72
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

×