a framework for testing in scrum projects
DESCRIPTION
A Framework for Testing in Scrum Projects. Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: [email protected] w: http://gerrardconsulting.com t: 01628 639173. SCRUM. ...like Agile... love it or hate it – it’s here to stay. Scrum. - PowerPoint PPT PresentationTRANSCRIPT
A Framework for Testing in Scrum Projects
Assurance with Intelligence
Paul GerrardGerrard Consulting1 Old Forge CloseMaidenheadBerkshireSL6 2RD UKe: [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
Assurance with Intelligence Slide 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 Slide 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 Slide 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 Slide 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 Slide 8
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?
Assurance with Intelligence Slide 11
Key Agile Disciplines and Scrum
Assurance with Intelligence Slide 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 Slide 13
We do Scrum. We do stories.
We are Agile.Really?
Assurance with Intelligence Slide 14
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
Assurance with Intelligence Slide 18
“Done”
When we run out of time
Assurance with Intelligence Slide 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 Slide 20
What’s Going on Here?
Assurance with Intelligence Slide 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 Slide 22
What happened?• Incompetent development shops
using Agile/scrum as a figleaf?• Structured development shops
cherry-picking the practices they like?
Assurance with Intelligence Slide 23
Where Should Testing Happen in Scrum?Towards a Scrum Testing
Framework
Assurance with Intelligence Slide 24
Existing Code base
New Code
Sprint 1
Developed Stories Developed Stories Developed Stories
Sprint 3Sprint 2
Sprint Backlog Sprint Backlog Sprint Backlog
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
Assurance with Intelligence Slide 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 wordUser text
Stories may have many scenarios
Assurance with Intelligence Slide 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 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
Developed Stories Developed Stories Developed Stories
Sprint 3Sprint 2
Sprint Backlog Sprint Backlog Sprint Backlog
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.
Assurance with Intelligence Slide 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 Slide 31