WHITE PAPER

THE AGILE TESTER

JoEllen Carter

EXECUTIVE SUMMARY
CONTENTS

Executive Summary...................................................................................... 1

Introduction...................................................................................................... 1

Traditional QA................................................................................................. 1

Agile Testing Explained.............................................................................. 2

New Skills for the Agile Tester ................................................................ 2

The Tester and the Team............................................................................3

Conclusion.......................................................................................................6

INTRODUCTION

A mature QA process serves an

important purpose, one which must be
retained in the transition to agile.

TRADITIONAL QA

1
WHITE PAPER
In addition, business requirements often change after test
cases are developed, requiring extensive test case re-
writes and test plan changes, if the requirement changes
are communicated to both development and QA. If
requirement changes aren’t communicated consistently,
there’s a risk that business analysts, developers and QA
may have different expectations of the final product.
As test case automation has become increasingly
important, QA teams have had to incorporate another
significant activity into the workflow. Larger organizations
may have a completely separate automation group that
delivers automated test cases to the QA product team.
This adds another layer of required communication to an
already significant load.
Finally, since QA is usually the last activity before a
fixed release date, many planned QA activities may get
squeezed from the schedule, compromising product
quality.
AGILE TESTING EXPLAINED
Agile testing follows a more fluid, continuous process
which takes place hand-in-hand with development
and product management. An agile team doesn’t do
all of the requirements work for a system, then all of
the development work and then all of the testing work
consecutively. Instead, the agile team takes a small piece
of the system and works together to complete that piece
of the system. The piece may be infrastructure-related,
feature development or a research spike. Then the team
takes on another small piece and completes that piece.
The project marches toward completion piece by piece.
Completing a piece of the system, referred to as a story
or backlog item, means that product management,
development and testing work together toward a
common goal. The goal is for the story to be ‘done.’
Stories are identified and prioritized by the product
owner, who manages the backlog. Stories are selected
based on their priority and effort estimate. The effort
estimate is another team activity, which also includes
testers. The team also identifies dependencies, technical
challenges, or testing challenges. The whole team agrees
on final acceptance criteria for a story to determine when
it’s ‘done’.
During an iteration, several stories may be in various
stages of development, test, or acceptance. Agile
testing is continuous, since everyone on an agile team
tests. However, both the focus and timing of testing is
different depending on what type of testing is performed.
Developers take the lead on code-level tests, while the
The Agile Tester
tester on the agile team provides early feedback during all
stages of development, helps or is cognizant of code-level
testing being performed, takes the lead on acceptance
test automation building regression test plans and
uncovers additional test scenarios through exploratory
testing.
In addition, the agile tester ensures acceptance test
coverage is adequate, leads automation efforts on
integrated, system-level tests, keeps test environments
and data available, identifies regression concerns and
shares testing techniques. Additional testing, such as
performance and regression testing, that falls outside the
scope of story-level testing, can be addressed through
test-oriented stories, which are estimated, planned and
tracked just like a product-oriented story.
NEW SKILLS FOR THE AGILE TESTER
Transitioning from a QA Engineer to an agile tester means
more than a change in when the product is tested and
how much of it is tested at a time. There’s a new paradigm
for the agile tester — instead of being the Quality Police,
the agile tester is a team player and works with the team
to get each story to done. There are several skills that
make this paradigm shift a bit easier.
Team Member
The agile tester is a full-fledged, first-class member of
the agile team. The agile tester participates in planning,
estimating, scheduling, retrospectives and any other team
activities. Testers are generally thoughtful, analytical
problem solvers and often add a unique perspective to
the team in terms of identifying potential road blocks
and dependencies early in the process. Testers need to
participate as members of the agile team, not just the QA
team, to bring this information to the team’s attention as
soon as possible.
Exploratory Testing
Business requirements on an agile project may not be
as concrete as requirements on a traditional project;
agile methods accept that change is a healthy and real
part of software development. This means that test case
generation may not be as cut-and-dry as it was in the
past. Exploratory testing is an essential skill to uncover
additional considerations for the product owner to
evaluate. James Bach, Cem Kamer and other members of
the agile testing community have contributed numerous
excellent publications on exploratory testing techniques.
2
WHITE PAPER
Automation

Agile emphasizes automating as much as possible.

Agile works best with some level of automation. But
many teams struggle with when, how much and what
tools to use. While continuous integration (CI) is an
accepted developer practice, the agile tester takes the
lead on incorporating automated acceptance tests into
CI and raising the visibility of end-to-end and scenario
testing results. Automation is not a separate project or a
tester-only activity and it’s not just test case automation:
is part of the story delivery process. Automation is
anything that allows the team to work faster and the
whole team supports it.

Communication

QA Engineers tend to rely on documents. Agile testers

don’t get a big requirements document as a basis for
test cases and don’t get three months to write test cases
before they see a working piece of code. They jump
into the communication stream, which may be verbal,
written, or virtual and assimilate the information they
need. They learn to ask the right questions at the right
time and provide the right level of feedback at the right
time.

THE TESTER AND THE TEAM

A single story walkthrough demonstrates what an agile tester does as part of an agile team. Here’s a simple story that
might be presented to an agile team:

An agile tester will contribute to the team from the time the story is presented to the team to when it’s completed, not
just during testing. Let’s look at specific contributions during these phases of work:
• Story Exploration
• Estimation
• Story Planning
• Story Progression
• Story Acceptance

The Agile Tester 3

WHITE PAPER
Story Exploration

A story does not magically appear. There’s been work to get it to the team for implementation. The product owner has
researched the functionality, prioritized, ranked and sequenced it with other stories. However, this work has not been
done in a vacuum. Communication within an agile team is constant. Information flows between the product owner,
developers and testers continuously. The product owner may groom the backlog, but not without input and consensus
from the rest of the team. The product owner keeps the whole team aware of the product roadmap and future features
that are targeted for implementation. Every team member has some level of knowledge about the story and how it fits
into the big picture.

The product owner shares this information through:

• Visible product roadmap
• Release overviews

• Iteration planning

When it’s time to schedule a story, the whole team will gather to explore the story and make sure everyone on the team
understands the scope. An agile tester might ask questions to clarify the scope of the story.
• Is this option only on the login page?
• Has the application sent email before, or is that a new interface?

The agile tester might also ask questions to clarify any vagueness in the story.
• What does it mean for an email address to be ‘unknown’?
• What does it mean to ‘require confirmation’ of the password?

Asking questions at this point is a delicate skill. It’s expected that there will be some unknowns in the system at this
point and there’s a certain amount of discovery that will be done as the story progresses. The idea here is to get just
enough clarity to be able to estimate the story, which is the next step. After refinements to the story, it might look like
this:

Notice how much more ‘testable’ the

story became. The additional detail
and clarification is valuable as the team
prepares to estimate the size of the
story.

Estimation

Estimation is another team activity to

which agile testers should contribute.
Different teams estimate at different
times. One team might estimate as
part of iteration planning. Another
team might estimate as part of release
planning. Yet another team might
estimate at a high level for release
planning purposes and then by more
detailed story points in iteration
planning. Every team needs to find what
works for their team, including how to
treat testing.

The Agile Tester 4

WHITE PAPER

The Agile Tester 5

WHITE PAPER
CONCLUSION

AUTHOR’S BIO

ABOUT VERSIONONE
VersionOne is recognized by agile practitioners as the leader in
agile project management tools. By simplifying the planning and
tracking of agile projects, we help teams deliver better software
faster. Since 2002, companies such as Adobe, Dow Chemical,
Lockheed Martin, Motorola, Novell, Sony and Symantec have
turned to VersionOne. Today more than 30,000 teams from over
170 countries use VersionOne.
Start small. Scale smart. See for yourself at www.VersionOne.com.

© 2010, VersionOne, Inc. All Rights Reserved. The Agile Management Company. V1_0410

The Agile Tester 6