agile testing, uncertainty, risk, and why it all works
DESCRIPTION
Testing is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.TRANSCRIPT
Agile Testing, Uncertainty, Risk, and Why It All Works Elisabeth Hendrickson
Quality Tree Software, Inc. www.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.
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.
It’s Not Done Until It’s Tested
We’re really behind. Let’s just call it “done” and
move on.
But what if it doesn’t
work?
It’s not releasable until it’s Done. (Really Done.) Done includes both implemented and tested.
And tested means checked and explored.
Testing: Consider Certainty v. Time
Sequence of Sprints
Single Sprint
“Traditional” Release
Illusion Buildup Ill
usion
Time
Four Big Sources of Technical Risk
Ambiguity Dependencies
Assumptions Capacity
Eight Key Testing-Related Practices in Agile
ATDD TDD Exploratory Testing
Collective Test Ownership
Automated Unit Tests
Automated System Tests
Continuous Integration
Rehearse Delivery
Practice: Acceptance-Test Driven Development (ATDD)
Principle: Tests Represent Expectations
Test Driven practices make expectations explicit and drive out ambiguity early.
I found a great bug! It won’t run on a Commodore 64!
Ummm…and what gave you the idea that
should be a supported platform?
Principle: Reduce Test Documentation Overhead
ATDD provides leveraged documentation and results in executable requirements.
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
Principle: Reduce Feedback Latency
Latency
Practice: Test Driven Development (TDD)
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
Practice: Collective Test Ownership
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
Principle: Red Build Means Stop the Line
If a previously passing expectation fails, there’s a bug. Bugs slow everything down. To keep
sustainable pace, fix bugs fast.
We can just throw that bug on the pile
with the others.
Yuck.
But that will increase technical
debt & slow velocity.
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)
Principle: Fail Early, Fail Fast
Failing late results in panic. Failing early gives us time to fix
the problems.
Practice: Rehearse Delivery
Until we ship or deploy, we don’t
know what will go wrong getting a
“Done” system out the door.
Agile Testing Practices Mitigate Risk
Ambiguity Dependencies
Assumptions Capacity
ATDD
TDD
Exploratory Testing Rehearse
Delivery
Collective Test Ownership
Automated Unit Tests
Automated System Tests
Continuous Integration
Automated System Tests
Automated Unit Tests
Automated System Tests
Automated Unit Tests
Rehearse Delivery
Rehearse Delivery
Continuous Integration