Continuous Software Collaboration with Cucumber

698 views
620 views

Published on

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.

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

  • Be the first to like this

No Downloads
Views
Total views
698
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Continuous Software Collaboration with Cucumber

    1. 1. CucumberA Tool for Continuous Software Collaboration
    2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Me• Husband• Dad• Not yet a grandpa
    16. 16. Software Evolution<1998 Systems Development Life Cycle (SDLC) Waterfall Extreme1998- SDLC Programming2008 Test-Driven-Development (TDD) (XP) SDLC>2008 TDD Agile/Scrum Behavior-Driven Development (BDD)
    17. 17. WaterfallStakeholder(s) Everyone Else
    18. 18. Extreme Programming Stakeholder(s) Analysis Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests Implement Implement Implement
    19. 19. Agile/Scrum Stakeholder(s) Analysis Analysis AnalysisEvaluate Write Tests Evaluate Write Tests Evaluate Write Tests Implement Implement Implement
    20. 20. Agile/Scrum Stakeholder(s) Scrum Master Analysis Analysis AnalysisEvaluate Write Tests Evaluate Write Tests Evaluate Write Tests Implement Implement Implement
    21. 21. Agile/Scrum Stakeholder(s) Scrum Master Analysis Analysis AnalysisThis requires a lot of what I liketo euphemistically call Evaluate Write Tests Evaluate Write Tests Evaluate Write Tests Implement Implement Implement
    22. 22. The Challenge: Analysis Features: What to Include Analysis: How to Implement
    23. 23. The Challenge: Analysis Features: What to Include (No Automation) Analysis: How to Implement
    24. 24. BDD Objective1. 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. 25. What is Cucumber?• Cucumber is a software implementation of a BDD framework.• Competitors: • Fitnesse • Turnip, Steak, xBehave, others
    26. 26. What is Cucumber?• Hyper-High Level Specification Language
    27. 27. What is Cucumber?• Write a step definition (here in Ruby)
    28. 28. What is Cucumber?• Run and watch it fail
    29. 29. What is Cucumber?• Write code to make the step pass
    30. 30. What is Cucumber?• Run again and see the step pass: Evaluate Write Tests Implement
    31. 31. What is Cucumber?• Many tools support Cucumber annotation
    32. 32. What is Cucumber?• Repeat until steps are green like a cuke
    33. 33. What is Cucumber?• Repeat the previous steps until the money runs out
    34. 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. 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. 36. SpecificnessConsider:Vs:
    37. 37. JustificationConsider:Vs.
    38. 38. Prioritize on JustificationWill 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. 39. Appropriate DetailConsider:Vs:
    40. 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. 41. What Should NOT Go Into a Feature• Blatantly obvious functionality• End-to-end acceptance testing• Peripheral requirements
    42. 42. WhatGoesWrong
    43. 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. 44. Resistance to Preciseness• It is much easier to think in vague generalities than sweat the functional details.
    45. 45. Hazy Requirements• What should happen when each possible exceptional condition occurs?• Conflicting desired functionality Exhausting
    46. 46. Inexperience• Cucumber verifies mock-up sequences• “How” decisions creep into features• Failure to develop domain vocabulary• Features not developed collaboratively
    47. 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. 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. 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. 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. 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. 52. Obligatory Cat Video http://www.youtube.com/watch? v=yVjzd320gew&feature=channel&list=UL

    ×