Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BDD

  • Login to see the comments

BDD

  1. 1. Executable Requirements<br />Godfrey Nolan<br />RIIS LLC<br />GANG 10 Year Celebration<br />10/1/11<br />
  2. 2. SPAM<br />RIIS LLC - IT Consultants and Developers since ‘98<br />Based in Southfield, MI<br />Skills<br />Requirements, Development, Testing<br />iOS/Android, Java/C#, Oracle/SQL Server<br />Clients<br />Fandango, Federal APD, Comerica, Cengage, Broadsoft, DTE, BondDesk, Proctor Financial, Blue Cross Blue Shield MI, TK, Hanson<br />Godfrey Nolan<br />godfrey@riis.com<br />10 years ago – Unraveling the .Net executable<br />
  3. 3. Agenda<br />
  4. 4. What Makes a Good Requirement?<br />Unique – address one thing only<br />Complete – no missing information<br />Consistent – doesn’t contradict other requirement<br />Traceable back to business need<br />Current – not obsolete<br />Feasible – can be implemented<br />Unambiguous – objective facts not subjective opinions<br />Mandatory – not a nice to have<br />Verifiable – testable<br />
  5. 5. What makes a Bad Requirement?<br />Lengthy<br />Unfocused<br />Ambiguous<br />Verified Manually<br />
  6. 6. Attempts at Writing Good Requirements<br />RIIS History – yours may be different<br />Company Wide Templates<br />Use Cases or User Stories<br />Requirement Reviews<br />Traceability Matrix tools<br />Requirement Metrics tools <br />Visualization/Simulation tools – iRise, Axure, Balsamiq<br />Agile Development – TDD, Scrum, Kanban<br />ALM, CLM tools<br />
  7. 7. Use Case <br />Scope: ATM<br />Level: User Goal<br />1. The card gets inserted.<br />2. The card information gets validated.<br />3. The transaction information gets collected and validated.<br />4. The cash is issued, card returned, cash removed, account debited, screen reset.<br />
  8. 8. Use Cases <br />1. Customer runs ATM card through the card reader.<br />2. ATM reads the bank id and account number.<br />3. ATM asks customer whether to proceed in Spanish/English.<br />4. Customer selects language.<br />5. ATM asks for PIN number and to press Enter.<br />6. Customer enters PIN number, presses Enter.<br />7. ATM presents list of activities for the Customer to perform.<br />8. Customer selects “withdraw cash”.<br />9. ATM asks customer to say how much to withdraw, in multiples of $5, and to press Enter.<br />10. Customer enters an amount, a multiple of $5, presses Enter.<br />11. ATM notifies main banking system of customer account, amount being withdrawn.<br />12. Main banking system accepts the withdrawal, tells ATM new balance.<br />13. ATM delivers the cash.<br />14. ATM asks whether customer would like a receipt.<br />15. Customer replies, yes.<br />16. ATM issues receipt showing new balance.<br />17. ATM logs the transaction.<br />
  9. 9. User Story<br />1. User checks balance<br />2. User logs into the machine<br />3. User get "Fast Cash"<br />4. User makes a deposit<br />5. User withdraws from checking<br />6. User withdraws from savings<br />
  10. 10. Traceability Matrix<br />
  11. 11. Visualization<br />
  12. 12. But inevitably…<br />Some or all the following happen<br />Scope change<br />Requirements confusion, opinions not facts<br />Developer interprets the requirement<br />Business stakeholder doesn’t get what they’re expecting<br />Completelymissed some crucial requirement<br />Requirements never kept up to date<br />
  13. 13. But What if?<br />Imagine a world where developers get detailed requirements in a format and mechanism that is readable by the business facing people...<br />...completely devoid of ambiguity in terms of what the correct behavior is...<br />...and can also be used as an automated test within your team's continuous integration processes. (Tim Wingfield)<br />
  14. 14. But What If? (TechTalk)<br />
  15. 15. But What If?<br />
  16. 16. TDD<br />
  17. 17. Executable Requirements <br />
  18. 18. Executable Requirements<br />These were the Droids you were looking for..<br />BDD or Behavior Driven Design<br />Functional Tests<br />Integration Tests<br />Acceptance Tests<br />ATDD or Acceptance Test Driven Design<br />Specification by Example<br />Outside In Development<br />Executable Requirements<br />
  19. 19.
  20. 20. Outside In Development<br />
  21. 21. Manual Testing Problem (Matt Stine)<br />
  22. 22. Testing Pyramid (Lisa Crispin)<br />
  23. 23. Continuous Integration<br />
  24. 24. Continuous Integration<br />Automated Build Process<br />Code gets checked in<br />Unit tests run<br />Executable Requirements tests run<br />Code gets deployed only if everything passes<br />Requirements are kept up to date!<br />
  25. 25. Writing Executable Requirements<br />Features file <br />Written in DSL called Gherkin<br />Feature description<br />Scenario Outline<br />Given/When/Then<br />Examples (optional)<br />Sample test data<br />Step Definitions<br />Setup<br />Regular Expressions for each Given/When/Then<br />Executable C# test code<br />Tear down<br />
  26. 26. Writing Executable Requirements<br />
  27. 27. Given/When/Then<br />
  28. 28. What is SpecFlow<br />.Nettool to write Executable Requirement in Gherkin format<br />Integrates with Visual Studio 2010<br />File->New templates for creating new feature files<br />Code generation Glue between Feature and Step Definition files<br />Gives VS debugger support<br />Set breakpoints on Given/When/Then lines in your .feature files<br />Integrates with your existing CI infrastructure<br />Also integrates with<br />NUnit<br />Selenium<br />WatiN<br />
  29. 29. Good Executable Requirements<br />Understandable to developer<br />Understandable to business<br />Unambiguous<br />Automated<br />Run frequently<br />
  30. 30. Writing Executable Requirements<br />
  31. 31. Writing Executable Requirements<br />Features file<br />Feature description<br />Scenario Outline<br />Given/When/Then<br />Examples<br />Sample test data<br />
  32. 32. Feature File<br />
  33. 33. Writing Executable Requirements<br />Step Definitions<br />Setup<br />Regular Expressions for each Given/When/Then<br />Executable C# test code<br />Tear down<br />
  34. 34.
  35. 35. SpecFlow Glue<br />
  36. 36. Demo<br />SpecFlow demo<br />
  37. 37. Sample Features files<br />Feature: Account Holder withdraws cash <br />In order to have access to my money <br />As an Account Holder <br />I want to withdraw cash from an ATM <br />Scenario: Card has been disabled <br />Given card is disabled <br />When the account holder requests money <br />Then the ATM should retain the card <br />And the ATM should say the card has been retained <br />
  38. 38. Sample Features files<br />Feature: Serve coffee<br /> In order to earn money<br /> Customers should be able to <br /> buy coffee at all times<br /> Scenario: Buy last coffee<br /> Given there is 1 coffee left in the machine<br /> And I have deposited $1<br /> When I press the coffee button<br /> Then I should be served a coffee<br />
  39. 39. Languages and Tools<br />Languages<br />C# - Specflow, Cuke4Nuke, StorEvil<br />Ruby – Cucumber<br />Java – Cuke4Duke<br />Also Phython, PHP etc.<br />Tools<br />Cucumber<br />Selenium RC<br />Fitnesse<br />
  40. 40. Tear Down<br />Executable Requirements or Coding the right thing<br />Outside In Development<br />Works well in Scrum teams<br />BA does feature file<br />Developer/tester does step definitions <br />Works well with VS10<br />Evolutionary not Revolutionary<br />Might be for you if you’re asking the question?<br />What business requirement does code coverage really provide?<br />
  41. 41. Resources<br />URLs<br />http://www.specflow.org<br />http://dannorth.net/whats-in-a-story/<br />http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspx<br />http://cukes.info<br />Books<br />

×