The document discusses how too much testing can trap a team and product in a "death spiral". It describes a scenario where a team assembled to build a product but their testing strategy became ineffective and led to slower development and frustrated teams. The document then provides tips on how to avoid this, such as making sure unit tests actually test units, writing tests first, keeping dependencies loose, and evolving one's testing strategy so that testing serves the team rather than the other way around. It emphasizes that the goal is learning rather than failure.

1. Ash Winter
Short stuff here:
@northern_tester
Long stuff here:
Tweet on #AgileYorkshire

2. Tested to Death…
Or how
testing can
trap you in a
team and
product death
spiral

3. So, I’m a tester right…
• Weird topic
• Too much testing
is bad
• Serving tests is
bad
• Testing the same
thing at different
levels can be bad

4. Pop quiz hotshots…
Quick state of the nation.
How many of you…
• Think you do too much
testing?
• Think you do too little
testing?
• Think your testing is
effective?

5. Let me tell you a story…
•Fansz
•Great
dudes
assembled
•Ready FTW

6. There was a strategy…
You’ve all
seen the
testing
pyramid
before
right?

7. Funny business…
Unit Tests ==
Integration Tests ==
Acceptance Tests

8. Nosey parkers…
Integration
tests poked
their noses
in unit and
acceptance
tests
business.

9. Weird smells…
Change the
tests to
get the
code to
pass?

10. Eyebrows raised…
Injected dependencies
were mocking us…

11. Brows furrowed…
Lets try other test
runners. That will help.

12. Quicksand…
• New
stuff?
Slow
• Change
stuff?
Slower

13. Worst of all, sad faces…
• Frustrating,
endless
discussion
• Sad
dependant
teams
• Sad sponsors

14. Ultimately…
A Dream
(and Team)
Expired*
*Really not the
only reason.
Didn’t help

15. But don’t despair…
In life
and
testing,
there is
no fail,
only
learning!

16. #1 All tests must die
• Tests have a
life and a death
• You CAN kill
them ALL!
• Be pointy with
tests that pass
ALL the time!

17. #2 Chasing sunk cost
will sink you
• Inventory
• 1 line of
code, change
800 tests
• Think value,
not cost

18. #3 Unit Tests?
• Erm
• Make sure
you are
actually
writing
unit tests

19. #4 You can write tests
first…
• Your app is
not special
• More likely
to have
only the
tests you
need

20. #5 Dependencies
You are the
child, the
dependency
is the
parent

21. #6 Checkocalypse Now
How many
times do you
need to
check 1 + 1
= 2?

22. #7 Small
• Very small
packs of
tests that
reflect the
system
• Separate
ignored tests
• Then destroy
them!

23. #8 Pairing is smart
• Two brains
write better
tests
• Hint -
Especially a
tester and
dev

24. #9 Use more than one model
• Marick's Quadrants par
example
• Too many technology
facing tests…

25. #n Context or ‘it
depends’
We weren’t
even in
beta.
(gently
weeps)

26. And in summary…
• Testing is
great!
• Evolve your
strategy!
• It serves you,
not the other
way around…

27. Questions?