A Framework for Testing in Scrum Projects Assurance with Intelligence Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: w: t:

Paul Gerrard Paul is the founder and Principal of Gerrard Consulting, a services company focused on increasing the success rate of IT-based projects for clients. He has conducted assignments in all aspects of Software Testing and Quality Assurance. Previously, he has worked as a developer, designer, project manager and consultant for small and large developments using all major technologies and is the webmaster of gerrardconsulting.com and several other websites. Paul has degrees from the Universities of Oxford and London, is Web Secretary for the BCS SIG in Software Testing (SIGIST), Founding Chair of the ISEB Tester Qualification Board and the host/organiser of the UK Test Management Forum conferences. He is a regular speaker at seminars and conferences in the UK, continental Europe and the USA and was recently awarded the “Best Presentation of the Year” prize by the BCS SIGIST. Paul has written many papers and articles, most of which are on the Gerrard website. With Neil Thompson, Paul wrote “Risk-Based E-Business Testing” – the standard text for risk-based testing. Assurance with IntelligenceSlide 2

SCRUM......like Agile... love it or hate it – it’s here to stay Assurance with IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 8

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

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

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 IntelligenceSlide 11

Key Agile Disciplines and Scrum Assurance with IntelligenceSlide 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 IntelligenceSlide 13

We do Scrum. We do stories. We are Agile. Really? Assurance with IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 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 IntelligenceSlide 17

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

“Done” When we run out of time Assurance with IntelligenceSlide 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 IntelligenceSlide 20

What’s Going on Here? Assurance with IntelligenceSlide 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 IntelligenceSlide 22

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

Where Should Testing Happen in Scrum? Towards a Scrum Testing Framework Assurance with IntelligenceSlide 24

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

Story Structure Assurance with IntelligenceSlide 26 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

Stories may have many scenarios Assurance with IntelligenceSlide 27 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 is sent to the purchasers address” Scenario: “advise an item is discontinued” Given “I select a valid order” And “the ordered book is discontinued” Key word User text

Daily Scrum Stand-Up Meeting 24 Hours 2-4 Weeks Backlog tasks expanded by team Potentially Shippable Product increment Product backlog As prioritised by Product Owner Sprint Backlog 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 3. Daily Stand-Up Report anomalies found, stories tested, amended, created Test Activities in the Sprint

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

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 IntelligenceSlide 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 IntelligenceSlide 31