1 / 30

A Framework for Testing in Scrum Projects

A Framework for Testing in Scrum Projects. Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: paul@gerrardconsulting.com w: http://gerrardconsulting.com t: 01628 639173. SCRUM. ...like Agile... love it or hate it – it’s here to stay. Scrum.

jam
Download Presentation

A Framework for Testing in Scrum Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Framework for Testing in Scrum Projects Paul GerrardGerrard Consulting1 Old Forge CloseMaidenheadBerkshireSL6 2RD UK e: paul@gerrardconsulting.comw: http://gerrardconsulting.comt: 01628 639173 Assurance with Intelligence

  2. SCRUM... ...like Agile... love it or hate it – it’s here to stay Assurance with Intelligence

  3. Scrum • Promoted as an Agile approach to managing software development • In fact, the roots of Scrum date back 30 years • Japanese management style as alternative to staged development (of anything, but usually manufacturing) • Autonomous team of specialists • Everyone moves forwards together rather than hands-off between stages • Pass the ball to the person who needs to work on the problem next • Fast, flexible, iterative, incremental Assurance with Intelligence

  4. Characteristics • Roles • Scrum Master • Product Owner • Developer • Three levels of activity and control • The Project • The Sprint iteration • Daily Scrums (stand-ups) Assurance with Intelligence

  5. Requirements • Requirements are enabled (not defined) by stories • Stories can be ‘one-liners’ that are a ‘trigger for a conversation’ • Written on cards (or spreadsheet or Wiki) • Requirements aren’t written down, they are captured as tests, manifested in code • Test-Driven Development. Assurance with Intelligence

  6. Backlogs and Planning • All Stories placed on the Product backlog – ready to be selected, implemented in Sprints • Sprint Planning (2-4 weeks) • Stories are considered, estimated and selected for the Sprint backlog • Product Owner – prioritises, advises • Developers estimate • Scrum Master organises Assurance with Intelligence

  7. The Sprint • Developers talk to users, work directly from conversations • Test-Driven Development • Construct unit tests from conversations • Write the code, run tests, fix bugs • Repeat until tests pass • Daily Scrums or stand-ups • Demonstrate functionality to users • Refine tests • Refine code • When all stories are implemented, baseline the delivery • Plan the next Sprint Assurance with Intelligence

  8. Scrum Project (This diagram shows three sprints, but there could be more or fewer) Product Backlog Sprint Backlog Sprint Backlog Sprint Backlog Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Existing Code base

  9. The Sprint Daily Scrum Stand-Up Meeting 24 Hours 2-4 Weeks Backlog tasks expandedby team Sprint Backlog Potentially ShippableProduct increment Product backlog As prioritised by Product Owner

  10. Testing in Scrum – yeah right • Most Scrum users seem to use some flavour of Extreme Programming • Testing in Scrum: • Developers do some (TDD possibly) • Users do some during Sprints, and at the end • ‘Other’ testing sort of happens • Scrum doesn’t makes the tester’s role explicit • Where does the tester fit in this? Assurance with Intelligence

  11. Key Agile Disciplines and Scrum Assurance with Intelligence

  12. Some Critical Agile disciplines Test-First Development Pair Programming On-Site Customer Refactoring (with Continuous Integration) Definition of ‘Done’ Nothing written down Trust the customer Assurance with Intelligence

  13. We do Scrum. We do stories. We are Agile. Really? Assurance with Intelligence

  14. We don’t do TDD – developers don’t like it No regression tests Design-free codebase is a mess Can’t refactor – way too dangerous! Assurance with Intelligence

  15. We don’t do pair-programming – it’s too wasteful No independent developer view? No one challenges the design/code? Users are getting un-tested code? Assurance with Intelligence

  16. We can’t have on-site customer – they’re too busy Large gaps between injections of user knowledge Code is a mass of assumptions Nothing finished, accepted, or ‘done’ Assurance with Intelligence

  17. We Can’t Refactor Users are pushing us too hard No time to refactor Too busy writing new code Assurance with Intelligence

  18. “Done” When we run out of time Assurance with Intelligence

  19. “We’re Agile” – yeah right Code is an un-designed mess that can’t be improved safely It’s largely untested and does what our user wants – sometimes There is no documentation – don’t be silly There are no tests – didn’t need them There is no knowledge of the system Legacy Code? No, of course not! Assurance with Intelligence

  20. What’s Going on Here? Assurance with Intelligence

  21. Agile: an excuse for not doing things properly? • The familiar challenge • What can testers do? • Offer to help – but how? • Stand and stare? • Look the other way? • Look for another project? • Look for another job? Assurance with Intelligence

  22. What happened? Incompetent development shops using Agile/scrum as a figleaf? Structured development shops cherry-picking the practices they like? Assurance with Intelligence

  23. Where Should Testing Happen in Scrum? Towards a Scrum Testing Framework Assurance with Intelligence

  24. Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) • Story Challenge • Suggest ‘what-ifs’ to challenge new stories Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the story definition Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Existing Code base

  25. Story Structure • Feature: • In order “to fullfil a book order” • As a “orders clark” • I want “to acknowledge and ship the order” • Scenario: “ship a single book from stock” • Given “I select a valid order” • And “the ordered book is in stock” • When “I choose ‘acknowledge and ship’” • Then “order status is changed to ‘shipped’” • And “an address label is printed” Key word User text Assurance with Intelligence

  26. Stories may have many scenarios • Feature: • In order “to fullfil a book order” • As a “orders clark” • I want “to acknowledge and ship the order” • Scenario: “ship a single book from stock” • Given “I select a valid order” • And “the ordered book is in stock” • When “I choose ‘acknowledge and ship’” • Then “order status is changed to ‘shipped’” • And “an address label is printed” • Scenario: “advise a book is our of stock” • Given “I select a valid order” • And “the ordered book is out of stock” • When “I choose ‘message the purchaser’” • Then “Enter message to purchaser advising the order status” • And “an email is sent to the purchasers email address” • Scenario: “advise an item is discontinued” • Given “I select a valid order” • And “the ordered book is discontinued” Key word User text Assurance with Intelligence

  27. Test Activities in the Sprint 3. Daily Stand-Up Report anomalies found, stories tested, amended, created Daily Scrum Stand-Up Meeting 24 Hours 4. Story Refinement Refine scenarios to enhance story definition, create system tests as stories, as required 5a) Sprint Testing - Developer 5b) Sprint Testing - Tester Perform story-tests, log defects, provide feedback, new stories or scenarios to document bugs 2-4 Weeks Backlog tasks expandedby team Sprint Backlog Potentially ShippableProduct increment Product backlog As prioritised by Product Owner

  28. Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) • Story Challenge • Suggest ‘what-ifs’ to challenge new stories Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the story definition Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Existing Code base Increasing Scope of Int. Sys. and UAT 6. Integration Test 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

  29. Stories as Requirements • Story headline sets the scope of a feature • Scenarios provide recognisable examples of the system in use • In effect, they are low level test cases • Given, when, then... • Pre-conditions, inputs, expected results • Could put logical statements in stories rather than examples • Stories then become Use Cases. Assurance with Intelligence

  30. Summary • Not many companies are doing Agile properly • Scrum looks like Agile but it’s a joke without the supporting Agile disciplines • Testers can explore without requirements – that’s good, but not good enough most of the time • Testers could take role of Analyst/Tester and elaborate stories with examples • Scenarios provide: • Low level unit tests • Building blocks for system tests • A shopping list for user Tests • Not Agile? Who cares? It’s better than a joke. Assurance with Intelligence

More Related