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