Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start 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

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Agile Testing Days: Hitting a Moving Target

Presentation at Agile Testing Days, Berlin, October 2010.
by

David Evans

on 8 June 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Testing Days: Hitting a Moving Target

Problems
Risk
Agile QA
uality
ssurance
Dot these
Cross these
Failure to see the Whole
Good Testers ≠ Agile Testers?
Getting to 'Why?'
Done vs
Improved
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"
What's the
common thread?
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
Spending more
than the thing
is worth
...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'
Agility
is a state of mind,
not a process.
uestions
nswers
Asking the right



(Test analysis & design)
Getting fast and consistent



(Test execution)
Hitting a Moving Target
Agile Services Director, SQS
Agile Testing Days
Berlin, October 2010
David.Evans@sqs-uk.com
Twitter: @DavidEvans66
www.prezi.com
Thanks!
You
have
Power
User Story Dysfunction
Too much presumed design
Overstuffing the suitcase
Backlog as "parts-list"
Fixing Quality on Unfixed Scope
David Evans
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
the windscreen
What are we
improving?
Wiper Qualities
Control
Convenience-for-driver
All-weather effectiveness
Safety
.Visibility
.In_Wet_Weather
an alternative solution...
Courage
+ Safety
= Confidence
"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
How
good
is it?
does it do it?

Barely sufficient
(manual)
How can it be improved?
Motorised
What
How well
Self-parking
Multi-speed
Intermittent
Variable-speed
intermittent
Automatic (rain-sensing)
"Hidra" concept car with nano-technology self-cleaning glass
Optimisation Fallacies
Simplify
'What'

Improve
'How Well'

Dont treat stories like jigsaw pieces
Why?
Things Stakeholders actually care about
...the 'real' requirements
Agile Testing shapes and validates our mental model of the evolving system.
Local optimisation fails.
Don't measure
bus-speed

Cockburn
Patton
Gilb
‘Flat Backlogs just don’t cut it for me...’

Traditional story backlogs lose the
context from which they came.
Jeff
Tom
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
http://www.agileproductdesign.com/blog/the_new_backlog.html
Alastair
http://www.gilb.com/Requirements
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...
etc.

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
don't
to make a
Point
Move stories this way
Verification
Validation
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.
http://alistair.cockburn.us/Jeff+Patton+and+the+ABCs+of+Quality
This presentation available at: http://tinysqs.sqs-group.com/agiletd
Full transcript