BDD in Action - building software that matters

1. BDD in action Building software that matters

2. John Ferguson Smart Consultant Trainer Mentor Author Speaker Coder

6. So what is this BDD thing?

7. Using examples So what is this BDD thing?

8. Using examples a shared understanding So what is this BDD thing?

9. Using examples a shared understanding software that matters So what is this BDD thing?

10. BDD So what is this BDD thing?

11. BDD Collaboration So what is this BDD thing?

12. BDD Hunting out value Collaboration So what is this BDD thing?

13. BDD Hunting out value Collaboration Building the right software So what is this BDD thing?

14. BDD Hunting out value Automated Acceptance Criteria Collaboration Building the right software So what is this BDD thing?

15. BDD Hunting out value Automated Acceptance Criteria API and code design Collaboration Building the right software So what is this BDD thing?

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. 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. 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. 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. 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. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship

37. “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Solves the wrong problem well

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. “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. “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. “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. “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. You don’t know what you don’t know Understanding of what needs to be delivered Time

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. You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done

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. Business Goal Business Goal Business Goal “software that matters” We start with a business goal

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 ﬂy with Flying High rather than with a rival company.”

49. Business Goal Business Goal Business Goal “software that matters” What features will enable us to deliver this goal? FeaturesFeaturesFeatures

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 ﬂights

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 ﬂights Earn Frequent Flyer points from purchases

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 ﬂights Earn Frequent Flyer points from purchases View Frequent Flyer account balance online

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. 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 oﬀ with Bronze status”

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 oﬀ with Bronze status” “If she earns 300 points, she becomes a Silver Frequent Flyer member”

56. “Using examples”

57. “Using examples” •Explore requirements •Discover what we don’t know •Clarify ambigui8es •Iden8fy assump8ons and misunderstandings

58. “Using examples” “A new Frequent Flyer member starts oﬀ with Bronze status” •Explore requirements •Discover what we don’t know •Clarify ambigui8es •Iden8fy assump8ons and misunderstandings

59. “Using examples” “A new Frequent Flyer member starts oﬀ 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. “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. “Using examples” We express the examples in a structured format using simple English phrases

65. “Using examples” The automated acceptance criteria guide the development process

68. “a shared understanding”

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. BA Developer Tester Many teams build features like this… “a shared understanding”

71. Story BA Developer Tester Many teams build features like this… “a shared understanding”

72. Story Working code BA Developer Tester Many teams build features like this… “a shared understanding”

73. Story Working code boring manual tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”

74. Story bug reports Working code boring manual tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”

75. Story bug reports Working code boring manual tes5ng WASTE BA Developer Tester Many teams build features like this… “a shared understanding”

76. …but a little cooperation goes a long way… Story “a shared understanding”

80. …but a little cooperation goes a long way… Story Examples “a shared understanding”

81. …but a little cooperation goes a long way… Story Examples Automated acceptance criteria “a shared understanding”

82. …but a little cooperation goes a long way… Shared understanding Story Examples Automated acceptance criteria “a shared understanding”

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. …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. We call this “The Three Amigos” BA and/or product owner Tester Developer Automatable Acceptance Criteria Shared understanding “a shared understanding”

86. We call this “The Three Amigos” “a shared understanding”

91. “Automation without collaboration is empty”

92. Living Documentation

93. Living Documentation

94. Living Documentation Illustrates delivered features

95. Living Documentation A star5ng point for manual tests Illustrates delivered features

96. Living Documentation A star5ng point for manual tests Illustrates delivered features Progress repor5ng

97. Living Documentation A star5ng point for manual tests Illustrates delivered features Func5onal and technical documenta5on Progress repor5ng

98. Automated test results tell us…

99. Automated test results tell us… How many tests passed

100. Automated test results tell us… How many failed How many tests passed

101. Automated test results tell us… How many failed How many tests passed How many weren’t run

103. Automated test results tell us… What tests exist for a given feature

104. Automated test results tell us… What tests exist for a given feature How stable the feature is

106. Automated test results tell us… How a feature was tested

108. Automated test results tell us… What a feature looks like

112. Test results do not tell us what was not tested

113. Feature Coverage

114. Feature Coverage What stories are deﬁned for this feature?

115. Feature Coverage What stories are deﬁned for this feature? How many stories have automated acceptance criteria?

116. Feature Coverage What stories are deﬁned for this feature? How many stories have automated acceptance criteria? What acceptance criteria have been automated?

117. “Living Documentation completes the circle”

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”

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. 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. 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. “building the software right”

125. Acceptance criteria tell us what we need to build… “building the software right”

127. What would we like the API to look like? “building the software right”

131. Then write low-‐level speciﬁca8ons for the code “building the software right”

132. Then write low-‐level speciﬁca8ons for the code “building the software right”

134. “building the software right” These low level speciﬁca8ons become technical documenta8on for your APIs

135. “Every class is an API for someone”

136. BDD Gotchas 1 2 3 4

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. 1 2 3 4 BDD Gotchas

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. 1 2 3 4 5 BDD Gotchas

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. 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. 1 2 3 4 5 BDD Gotchas

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. 42 Beneﬁts of BDD •Focus eﬀort •Reduce waste and misaligned requirements

146. 43 Beneﬁts of BDD Deliver more valuable soYware

147. 44 Beneﬁts of BDD Make changes safely

148. 45 Beneﬁts of BDD Faster and more reliable releases

149. 46 Beneﬁts of BDD Reduced maintenance costs

150. BDD requires high business engagement and collabora8on Adoption challenges

151. BDD works best in an Agile or Itera8ve context Adoption challenges

152. BDD does not work well in a silo Adoption challenges

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. In conclusion… It’s behaviour all the way down

155. Want to learn more?

156. Want to learn more?

157. Want to learn more? http://thucydides.info/

158. Want to learn more? http://thucydides.info/ https://code.google.com/p/spock/

159. Thank You John Ferguson Smart john.smart@wakaleo.com wakaleo http://www.wakaleo.com

BDD in Action - building software that matters

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie BDD in Action - building software that matters

Ähnlich wie BDD in Action - building software that matters (20)

Mehr von John Ferguson Smart Limited

Mehr von John Ferguson Smart Limited (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

BDD in Action - building software that matters