A Quick overview of Behaviour Driven Development (BDD)

A Quick overview of Behaviour Driven Development (BDD)

• 1.
  Surrey STC Meetup,27/06/2013 Behaviour Driven Development Alan Parkinson @alan_parkinson
• 2.
  What do youknow about BDD? Hint: It‟s not about test automation
• 3.
  • Program doesnot do what it is intended • Fixed in development/QA • Program does what is intended • Unstated, misunderstood or tacit requirements IMPLEMENTATION DEFECT REQUIREMENTS DEFECT Software - What can go wrong?
• 4.
  A woman asksher husband, a programmer, to go shopping. She tells him “please, go to the nearby grocery store to buy some bread. Also, if they have eggs, buy 6”
• 5.
  50-60%of issues identifiedby testers can be chalked down as Requirements Defects 100-200%more expensive to fix than other defects because the code is already written
• 6.
  Why are developersgiven buggy requirements
• 7.
  Shouldn‟t we spendtime testing the requirements?
• 8.
  Anatomy of UserStories • Captures the 'who', 'what' and 'why„ • Simple, concise and often limited in detail • Acceptance criteria  Captures the business rules  The finish line
• 9.
  Capture contact detailsof Pet owners As a veterinary surgeon I want the Owners contacts details recorded So that I can contact them in an emergency to authorize treatment
• 10.
  Example Acceptance Criteria Ownersshould be prevented from entering invalid telephone numbers
• 11.
  Criteria to Scenarios Ifthe owner enters a telephone number that isn't exactly 11 digits long, the user should be presented with a message advising them to enter a valid telephone number.
• 12.
  Questions… If the ownerenters a telephone number that isn't exactly 11 digits long, the user should be presented with a message advising them to enter a valid telephone number. Is a country code required? Should a mobile telephone/cell be considered valid? What country‟s telephone number formats are considered valid?
• 13.
  Advantages of Scenarios •Scenarios do not replace Acceptance Criteria  Document and enhance acceptance criteria  Identify missing requirements details  Easy to validate against a system  Can be automated to validate a system • Simple communication tool  Natural languages  Everyone can understand
• 14.
  Too little detail Tied to Softwar e Design Goldie locks High Mainten ance Business Analysts DevelopersTesters The power of 3
• 15.
  Specification Workshop • Goals: Refine up coming User Stories with concrete Examples  Build common language  Reach a shared understanding • Inputs:  User Stories from the Product Backlog
• 16.
  How does BDDhelp? • All stakeholders involved in the discussion drives out clear and concise specifications centred around business value. • Write specifications in natural language so everyone is on the same page • Turn the specification into acceptance tests that guarantees the software does as it is intended • Use those tests as the software evolves to guarantee that it continues to work as intended. • Specifications are documentation – each scenario describes how the system is being used
• 17.
  Thursday 24th ofOctober 2013 Brighton
• 18.
  Thank you Alan Parkinson CEOand Co-founder, Hindsight Software Ltd alan.parkinson@hindsightsoftware.co.uk @alan_parkinson