Surrey STC Meetup BDD Presentation
•
0 gefällt mir•1,188 views
Many people believe Behaviour Driven Development (BDD) is about Test Automation. It's true that BDD and ATDD tools such as Cucumber and SpecFlow are often used in Test Automation however, that is only the tip of the proverbial iceberg. This is a rather narrow viewpoint which completely misses the benefits brought about by the hugely improved requirements and time saved as well as the cost savings brought about by these changes in workflow and development methodology. This talk was given at the Surrey Software Testing Club (STC) in Guildford.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Surrey STC Meetup BDD Presentation
Ähnlich wie Surrey STC Meetup BDD Presentation (20)
Mehr von Alan Parkinson
Mehr von Alan Parkinson (14)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Surrey STC Meetup BDD Presentation
- 1. Surrey STC Meetup, 27/06/2013 Behaviour Driven Development Alan Parkinson @alan_parkinson
- 2. What do you know about BDD? Hint: It‟s not about test automation
- 3. • Program does not 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 asks her 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 identified by 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 developers given buggy requirements
- 7. Shouldn‟t we spend time testing the requirements?
- 8. Anatomy of User Stories • 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 details of 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 Owners should be prevented from entering invalid telephone numbers
- 11. Criteria to Scenarios If the 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 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. 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 Developers Testers 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 BDD help? • 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 of October 2013 Brighton
- 18. Thank you Alan Parkinson CEO and Co-founder, Hindsight Software Ltd alan.parkinson@hindsightsoftware.co.uk @alan_parkinson
Hinweis der Redaktion
- The husband brings home 6 loaves of bread!
- Let’s take a look at the current situation state of requirements in Agile ProjectsUser stories are the basic unit of requirements in Agile project. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard
- Rather ambiguous exampleWhat does the business count as a invalid number?
- Can you see how much more specific this version is?A stakeholder could read this, and present use we an example of a valid telephone numberWe turned a single Acceptance Criterion into a Acceptance Test.
- Can you see how much more specific this version is?A stakeholder could read this, and present use we an example of a valid telephone numberWe turned a single Acceptance Criterion into a Acceptance Test.
- Three AmigosLeft to their own devices….Business AnalystsTypically put too little detail into scenarios, details focused on the wrong scenarioDevelopersDevelopers ended up turning scenarios into descriptions of their envisage software designTestersTypically write Scenarios similar to test scripts and cover every path. This ultimately makes the Scenarios have high maintenance costs when automated.