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

A Framework for Testing in Scrum Projects

Assurance with Intelligence

Paul GerrardGerrard Consulting1 Old Forge CloseMaidenheadBerkshireSL6 2RD UK

e: [email protected]: http://gerrardconsulting.comt: 01628 639173

SCRUM...

...like Agile...love it or hate it – it’s here to

stay

Assurance with Intelligence Slide 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


Characteristics

• Roles– Scrum Master– Product Owner– Developer

• Three levels of activity and control– The Project– The Sprint iteration– Daily Scrums (stand-ups)


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.


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


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


Existing Code base

New Code

Sprint 1

Developed Stories Developed Stories Developed Stories

Sprint 3Sprint 2

Sprint Backlog Sprint Backlog Sprint Backlog

Scrum Project (This diagram shows three sprints, but there could be more or fewer)Product

Backlog

Daily ScrumStand-UpMeeting 24

Hours

2-4 WeeksBacklog tasks

expandedby team

Potentially ShippableProduct incrementProduct 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?


Key Agile Disciplines and Scrum


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


We do Scrum. We do stories.

We are Agile.

Really?


We don’t do TDD – developers don’t like it

No regression testsDesign-free codebase is a

messCan’t refactor – way too

dangerous!Assurance with Intelligence Slide 15

We don’t do pair-programming – it’s too

wastefulNo independent developer

view?No one challenges the

design/code?Users are getting un-tested

code?Assurance with Intelligence Slide 16

We can’t have on-site customer – they’re too

busyLarge gaps between injections

of user knowledgeCode is a mass of

assumptionsNothing finished, accepted, or

‘done’Assurance with Intelligence Slide 17

We Can’t Refactor

Users are pushing us too hardNo time to refactor

Too busy writing new code


“Done”

When we run out of time


“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!


What’s Going on Here?


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?


What happened?

• Incompetent development shops using Agile/scrum as a figleaf?

• Structured development shops cherry-picking the practices they like?


Where Should Testing Happen in Scrum?

Towards a Scrum Testing Framework


Existing Code base

New Code

Sprint 1


Sprint 3Sprint 2


1. Story ChallengeSuggest ‘what-ifs’ to challenge new stories

2. Story DefinitionIntroduce scenarios to enhance the story definition

Project Level Test Activities(This diagram shows three sprints, but there could be more or fewer)

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 wordUser text

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 wordUser text

Daily ScrumStand-UpMeeting 24

Hours

2-4 WeeksBacklog tasks

expandedby team

Potentially ShippableProduct incrementProduct backlog

As prioritised by Product Owner

Sprint Backlog

4. Story RefinementRefine scenarios to enhance story definition, create system tests as stories, as required

5a) Sprint Testing - Developer 5b) Sprint Testing - TesterPerform story-tests, log defects, provide feedback, new stories or scenarios to document bugs

3. Daily Stand-UpReport 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


Sprint 3Sprint 2


1. Story ChallengeSuggest ‘what-ifs’ to challenge new stories

Increasing Scope of Int. Sys. and UAT

Increasing Scope of Integration, System and Users Testing

2. Story DefinitionIntroduce 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.


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.


Documents

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