An explanation of how Agile Testing practices work together to mitigate risk.

1. Agile Testing,
Uncertainty,
Risk, and
Why It All Works
Elisabeth Hendrickson
Quality Tree Software, Inc.
www.qualitytree.com
esh@qualitytree.com
Last updated April 27, 2010
Copyright © 2010 Quality Tree Software, Inc.
This work is licensed under the Creative Commons Attribution 3.0 United States License.
View a copy of this license.

2. What Does Agile Really Mean?
Agile software teams…
…Deliver value in the form of
releasable software at frequent
regular intervals (at least
monthly)…
…At a sustainable pace…
…While adapting to the changing
needs of the business.

3. It’s Not Done Until It’s Tested
We’re really But what if
behind. Let’s just it doesn’t
call it “done” and work?
move on.
It’s not releasable until it’s Done. (Really Done.)
Done includes both implemented and tested.
And tested means checked and explored.

4. Testing: Consider Certainty v. Time
“Traditional”
Release
Single Sprint
Sequence
of Sprints

5. Illusion Buildup
Illusion
Time

6. Four Big Sources of Technical Risk
Ambiguity Dependencies
Assumptions Capacity

7. Eight Key Testing-Related Practices in Agile
Exploratory
ATDD TDD
Testing
Automated Automated Collective Test
System Tests Unit Tests Ownership
Continuous Rehearse
Integration Delivery

8. Practice: Acceptance-Test Driven Development (ATDD)

9. Principle: Tests Represent Expectations
I found a great bug! Ummm…and what gave
It won’t run on a you the idea that
Commodore 64! should be a supported
platform?
Test Driven practices make expectations
explicit and drive out ambiguity early.

10. Principle: Reduce Test Documentation Overhead
ATDD provides leveraged documentation and
results in executable requirements.

11. Practice: Automated System-Level Regression Tests
• Are business-facing,
written by various members
of the team in collaboration
• Express expectations about
externally verifiable
behavior
• Represent executable
requirements

12. Principle: Reduce Feedback Latency
Latency

13. Practice: Test Driven Development (TDD)

14. Practice: Automated Unit Tests
• Are code-facing, written by
programmers to support
the coding effort
• Express expectations of the
internal behavior of the
code
• Isolate element(s) under
test
• Execute quickly and often

15. Practice: Collective Test Ownership

16. Practice: Continuous Integration (CI)
CI tools do
automated builds,
execute tests, and
report the results
Developers practicing CI
merge their changes
locally & execute tests
before checking in

17. Principle: Red Build Means Stop the Line
We can just throw But that will
that bug on the pile increase technical
with the others. debt & slow
velocity.
Yuck.
If a previously passing expectation fails, there’s a
bug. Bugs slow everything down. To keep
sustainable pace, fix bugs fast.

18. Practice: Exploratory Testing
Simultaneously…
…learning about the software
…designing tests
…executing tests
using feedback from the last
test to inform the next
(See Jon and James Bach’s work on Session-Based ET)

19. Principle: Fail Early, Fail Fast
Failing late results in
panic. Failing early
gives us time to fix
the problems.

20. Practice: Rehearse Delivery
Until we ship or
deploy, we don’t
know what will go
wrong getting a
“Done” system out
the door.

21. Agile Testing Practices Mitigate Risk
Continuous
ATDD Integration
Rehearse
Ambiguity Dependencies
Delivery
TDD Automated Automated
System TestsUnit Tests
Exploratory Continuous Collective Test
Rehearse Integration
Testing Rehearse
Ownership
Assumptions
Delivery Delivery
Capacity
Automated Automated Automated Automated
System Tests Unit Tests System TestsUnit Tests