Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Agile Testing Days: Hitting a Moving Target
Transcript of Agile Testing Days: Hitting a Moving Target
Failure to see the Whole
Good Testers ≠ Agile Testers?
Getting to 'Why?'
The Jigsaw Misconception
"We can't find enough testers
to resource all our agile development teams"
"Our testers are not able to keep up
with the output from development"
"There is not enough time
to complete regression testing"
"Developers complete their stories in a Sprint,
but the testers always overrun"
Building the thing wrong
Building the wrong thing
Building the right
thing, too late
Building something that doesn't last
...or incompatible with other platforms
than the thing
...or can't be used by those who need it
...or can be used by those who shouldn't
Quickly building a thing that's too slow
Building a quick thing, too slowly
Accepting Stories is not quite testing a system
A system is more than the sum of its features
Consistency, coherence, elegance, simplicity
Usability, security, performance, accessibility
Some good testing instincts don't always sit well in agile...
Expecting to test a stable, finished product
Trying to test too much at once
Wanting to know all the requirements first
Wanting to design tests based on an implementation
Focusing on 'how' before 'what', and 'what' before 'why'
is a state of mind,
not a process.
Asking the right
(Test analysis & design)
Getting fast and consistent
Hitting a Moving Target
Agile Services Director, SQS
Agile Testing Days
Berlin, October 2010
User Story Dysfunction
Too much presumed design
Overstuffing the suitcase
Backlog as "parts-list"
Fixing Quality on Unfixed Scope
Born: Adelaide, Australia
Reside: Cotswolds, UK
I would like to solve...
Too many people treat Stories like pieces in a jigsaw puzzle
It leads to the perception that the system is only complete when the final piece is added
This is not agile.
does it do?
Clears water from
What are we
an alternative solution...
"A late change in requirements...
is a competitive advantage"
- Mary Poppendieck
"Code that isn't tested doesn't work.
This seems to be the safe assumption."
- Kent Beck
"The product of testing is
- David Evans
does it do it?
How can it be improved?
"Hidra" concept car with nano-technology self-cleaning glass
Dont treat stories like jigsaw pieces
Things Stakeholders actually care about
...the 'real' requirements
Agile Testing shapes and validates our mental model of the evolving system.
Local optimisation fails.
‘Flat Backlogs just don’t cut it for me...’
Traditional story backlogs lose the
context from which they came.
Don’t use a flat backlog, use a two-dimensional map
Arrange mandatory user activities and tasks horizontally
Arrange the details, subtasks and improvements vertically
Don’t cut features, ‘thin’ them
In each iteration, enhance the details of mandatory activities
Identify the ‘Real’ requirements
Any project sponsor should be able to list the ‘real’ requirements
No more than a dozen, listed on one A4 page
Each should be objectively quantifiable
Project Requirements are expressed as Stakeholder Values
Identify the stakeholders for your project
e.g. Driver, Car Salesman, etc.
Understand what is valuable to them
e.g. Safety, Comfort, Running Cost...
Document those values that your project intends to improve
Include quantified goals (as values) where appropriate
Product Requirements are expressed as Quantifiable Qualities
Identify what product qualities will address stakeholder values
Safety: braking distance, visibility, road handling,
Costs: fuel economy, parts, insurance...
Comfort: noise levels, steering control, seat comfort...
Define the method for how each product quality can be measured
what scale applies for this measurement?
what 'meter' (test device) to use to get the measurement?
Each solution design (agile story) must directly improve some quality
Testing measures that improvement
Cockburn simplifies Kano
Reinterpreted Prof. Noriaki Kano’s “must-be” and “attractive” quality types
Categorise all options into A, B or C classes
A: Mandatory capabilities (e.g. Go, Stop, Steer)
B: Features/qualities on a quality gradient: the more of this, the better (e.g. fuel efficiency, horsepower, ride comfort, interior soundproofing)
C: Pleasant surprises (e.g. SatNav, audio in for MP3 player)
Cockburn unites Kano with Patton
To ‘thin’ requirements, don’t lump all potential feature aspects into one story
For any ‘mandatory’ (class ‘A’) requirement, move aspects to ‘B’ or ‘C’
In early iterations, complete the basic ‘A’ case for all user activities
to make a
Move stories this way
From the Latin 'verus', meaning 'true'. Verify that something is true or false.
From the Latin 'validus', meaning 'strong'. Validate that something is strong enough.
This presentation available at: http://tinysqs.sqs-group.com/agiletd