We hear a lot about how extending the test-driven cycle to the level of story specifications and acceptance criteria is key to high levels of agile success. Behavior-Driven Development's focus is even broader: what does the overall organization want a new software solution to do? Getting the various factions to work together to define and record this in a useful way is not easy. However, failing to do so inevitably risks much higher costs later on if development builds the wrong functionality. In May, join us as Scott Smith shows us how his company is progressing with Behavior-Driven Development using the popular tool Cucumber. The tool is simple (and the demo therefore mercifully short) but its challenges for the organizational culture are tectonic. Scott will show us how, in fits and starts, his organization is learning to work together to develop a shared vision of the product requirements. Your Speaker: Scott Smith has participated in software development since 1969, specializing in business development and test since 1989. He has been working in Ruby on Rails since 2009 and has been deeply influenced by the Extreme Programming movement since 2004. Presently he works for Hedgeye Risk Management and is an organizer for both the local Ruby and EmberJS user groups.

1. Cucumber
A Tool for Continuous Software Collaboration

2. Agenda
• Me (boring so will be brief)
• SDLC ->TDD->BDD evolution survey
• Overview of Cucumber
• Challenges Starting Up BDD in an
organization.
• What makes BDD worth it.
• My experience with BDD

3. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

4. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

5. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

6. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

7. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

8. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

9. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

10. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

11. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

12. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

13. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

14. Me
Scott Smith aka OldFartDeveloper
BSEE 1972 CS was a math minor
Hardware/Firmware ATE (always interested
/Software in test)
Berlin Wall Down 1990 Switched to business
software
Late 1990’s Became web developer
2005 - TDD Changed my life

15. Me
• Husband
• Dad
• Not yet a
grandpa

16. Software Evolution
<1998 Systems Development Life Cycle (SDLC) Waterfall
Extreme
1998- SDLC
Programming
2008 Test-Driven-Development (TDD)
(XP)
SDLC
>2008 TDD Agile/Scrum
Behavior-Driven Development (BDD)

17. Waterfall
Stakeholder(s)
Everyone Else

18. Extreme Programming
Stakeholder(s)
Analysis
Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests
Implement Implement Implement

19. Agile/Scrum
Stakeholder(s)
Analysis Analysis Analysis
Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests
Implement Implement Implement

20. Agile/Scrum
Stakeholder(s)
Scrum Master
Analysis Analysis Analysis
Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests
Implement Implement Implement

21. Agile/Scrum
Stakeholder(s)
Scrum Master
Analysis Analysis Analysis
This requires a lot of what I like
to euphemistically call Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests
Implement Implement Implement

22. The Challenge: Analysis
Features: What to Include
Analysis: How to Implement

23. The Challenge: Analysis
Features: What to Include
(No Automation)
Analysis: How to Implement

24. BDD Objective
1. BDD focuses on developing a clear
understanding of desired software behavior
through discussion with stakeholders.
2. This understanding is recorded in a natural
(i.e. domain) language readable by non-
programmers.
3. The natural language can be programmatically
interpreted to provide tests to drive code

25. What is Cucumber?
• Cucumber is a software implementation of a
BDD framework.
• Competitors:
• Fitnesse
• Turnip, Steak, xBehave, others

26. What is Cucumber?
• Hyper-High Level Specification Language

27. What is Cucumber?
• Write a step definition (here in Ruby)

28. What is Cucumber?
• Run and watch it fail

29. What is Cucumber?
• Write code to make the step pass

30. What is Cucumber?
• Run again and see the step pass:
Evaluate Write Tests
Implement

31. What is Cucumber?
• Many tools support Cucumber annotation

32. What is Cucumber?
• Repeat until steps are green like a cuke

33. What is Cucumber?
• Repeat the previous steps until the money
runs out

34. What is Cucumber?
• Cucumber lets software development teams describe how
software should behave in plain text. The text is written in a
business-readable domain-specific language and serves
as documentation, automated tests and development-aid -
all rolled into one format.
• Introduced in 2008 in Ruby. Since then, has been
expanded to Ruby, Java, .NET, Flex, Javascript (new), and
web applications written in any language
• Translated to over 40 spoken languages.

35. Cucumber:
Collaboration
• Specific examples, not vague descriptions
• Before examples, justification
• Highest priority: clarity to non-
programmers
• Appropriate level of detail
• Avoid repetitive detail; presentation is
important

36. Specificness
Consider:
Vs:

37. Justification
Consider:
Vs.

38. Prioritize on
Justification
Will this feature...
• Significantly enhance and/or protect the
core vision of the product?
• Specifically appeal to a customer need?
• Enhance revenue?
• Save resources? (labor/time/equipment)
If not, why are you considering it? Drop it.

39. Appropriate Detail
Consider:
Vs:

40. What Should Go Into a
Feature?
• Anything the team wants information from
the stakeholders about:
• Business rules
• Especially core-business values
• What, not how.
• Needs to be justified

41. What Should NOT Go
Into a Feature
• Blatantly obvious functionality
• End-to-end acceptance testing
• Peripheral requirements

42. What
Goes
Wrong

43. Stakeholder Distracted
by Pretty Pictures
• It is easy to become preoccupied by screen
design and form layout (mockups).
• But:
• What are the flows?
• What are the exceptional conditions and
what do we do about them?

44. Resistance to
Preciseness
• It is much easier to think in vague
generalities than sweat the functional
details.

45. Hazy Requirements
• What should happen when each possible
exceptional condition occurs?
• Conflicting desired functionality
Exhausting

46. Inexperience
• Cucumber verifies mock-up sequences
• “How” decisions creep into features
• Failure to develop domain vocabulary
• Features not developed collaboratively

47. Disengagement
• Stakeholder(s) not participating
• Not all participants can see all the
docs.
• Feature development trails off
• Deterioration into “Seven Stages of
a Project”

48. OMG! Why Do This?
• Lean Startup Mantra: “Fail Early”
• You were going to run into all the problems
later down the line anyways; now you
encounter them early when you can still do
something about it.
• You always know where you are.

49. BDD Is Hard! But Very
Effective!
• The alternatives are much harder and
demoralizing.
• The BDD fundamentals are easy to learn,
but the implications take practice
• Feature-wise, aim low at first; measure
carefully your velocity. Then adjust.
• Otherwise, exhaustion takes over

50. Author’s Experience
• Reintroduced Cucumber after 2 year
hiatus.
• New Product VP loves it, but the team is
learning all over again.
• Feature development revealed all kinds of
problems early. Cucumbers incomplete.
• Forced a much more realistic schedule; thus
far have avoided another death march.

51. Takeaways
• A good BDD tool applied in a collaborative
way will quickly expose the root causes of
an organization’s deficiencies and suggest
useful remedies.
• Must have management buy-in.
• Culture change is hard. Discipline is hard.
• Real organizational growth is rewarding.

52. Obligatory Cat Video
http://www.youtube.com/watch?
v=yVjzd320gew&feature=channel&list=UL