8/3/2019 WP_AgileTester

1/6

CONTENTS

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

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

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

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

New Skills or the Agile Tester ...............................................................2

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

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

A mature QA process serves an

important purpose, one which must be

retained in the transition to agile.

8/3/2019 WP_AgileTester

2/6

In addition, business requirements oten change ater test

cases are developed, requiring extensive test case re-

writes and test plan changes, i the requirement changes

are communicated to both development and QA. I

requirement changes arent communicated consistently,

theres a risk that business analysts, developers and QA

may have dierent expectations o the nal product.

As test case automation has become increasingly

important, QA teams have had to incorporate another

signicant activity into the workfow. Larger organizations

may have a completely separate automation group that

delivers automated test cases to the QA product team.

This adds another layer o required communication to an

already signicant load.

Finally, since QA is usually the last activity beore a

xed release date, many planned QA activities may get

squeezed rom the schedule, compromising product

quality.

AGILE TESTING EXPLAINED

Agile testing ollows a more fuid, continuous process

which takes place hand-in-hand with development

and product management. An agile team doesnt do

all o the requirements work or a system, then all o

the development work and then all o the testing work

consecutively. Instead, the agile team takes a small piece

o the system and works together to complete that piece

o the system. The piece may be inrastructure-related,

eature 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 o the system, reerred to as a story

or backlog item, means that product management,

development and testing work together toward a

common goal. The goal is or the story to be done.

Stories are identied and prioritized by the product

owner, who manages the backlog. Stories are selected

based on their priority and eort estimate. The eort

estimate is another team activity, which also includes

testers. The team also identies dependencies, technical

challenges, or testing challenges. The whole team agreeson nal acceptance criteria or a story to determine when

its done.

During an iteration, several stories may be in various

stages o development, test, or acceptance. Agile

testing is continuous, since everyone on an agile team

tests. However, both the ocus and timing o testing is

dierent depending on what type o testing is perormed.

Developers take the lead on code-level tests, while the

tester on the agile team provides early eedback during al

stages o development, helps or is cognizant o code-leve

testing being perormed, 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 eorts on

integrated, system-level tests, keeps test environments

and data available, identies regression concerns and

shares testing techniques. Additional testing, such as

perormance and regression testing, that alls outside the

scope o 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 rom a QA Engineer to an agile tester meansmore than a change in when the product is tested and

how much o it is tested at a time. Theres a new paradigm

or the agile tester instead o 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 shit a bit easier.

Team Member

The agile tester is a ull-fedged, rst-class member o

the agile team. The agile tester participates in planning,

estimating, scheduling, retrospectives and any other team

activities. Testers are generally thoughtul, analytical

problem solvers and oten add a unique perspective to

the team in terms o identiying potential road blocks

and dependencies early in the process. Testers need to

participate as members o the agile team, not just the QA

team, to bring this inormation to the teams 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 o sotware 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 or the product owner to

evaluate. James Bach, Cem Kamer and other members o

the agile testing community have contributed numerous

excellent publications on exploratory testing techniques.

8/3/2019 WP_AgileTester

3/6

8/3/2019 WP_AgileTester

4/6

Story Exploration

A story does not magically appear. Theres been work to get it to the team or implementation. The product owner has

researched the unctionality, 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. Inormation fows between the product owner,

developers and testers continuously. The product owner may groom the backlog, but not without input and consensus

rom the rest o the team. The product owner keeps the whole team aware o the product roadmap and uture eatures

that are targeted or implementation. Every team member has some level o knowledge about the story and how it ts

into the big picture.

The product owner shares this inormation through:

Visible product roadmap

Release overviews

Iteration planning

When its 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 clariy the scope o the story.

Is this option only on the login page?

Has the application sent email beore, or is that a new interace?

The agile tester might also ask questions to clariy any vagueness in the story.

What does it mean or an email address to be unknown?

What does it mean to require conrmation o the password?

Asking questions at this point is a delicate skill. Its expected that there will be some unknowns in the system at this

point and theres a certain amount o 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. Ater renements to the story, it might look like

this:

Notice how much more testable thestory became. The additional detail

and clarication is valuable as the team

prepares to estimate the size o the

story.

Estimation

Estimation is another team activity to

which agile testers should contribute.

Dierent teams estimate at dierent

times. One team might estimate as

part o iteration planning. Another

team might estimate as part o releaseplanning. Yet another team might

estimate at a high level or release

planning purposes and then by more

detailed story points in iteration

planning. Every team needs to nd what

works or their team, including how to

treat testing.

8/3/2019 WP_AgileTester

5/6

8/3/2019 WP_AgileTester

6/6

VersionOne is recognized by agile practitioners as the leader inagile 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.

ABOUT VERSIONONE

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