EXECUTIVE SUMMARY

INTRODUCTION

TRADITIONAL QA

1

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

JoEllen CarterTHE AGILE TESTER

A mature QA process serves an important purpose, one which must be retained in the transition to agile.

WHITE PAPER

The Agile Tester 2

WHITE PAPERIn 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 di!erent 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 e!ort estimate. The e!ort 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 di!erent depending on what type of testing is performed. Developers take the lead on code-level tests, while the

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 e!orts 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.

The Agile Tester 3

WHITE PAPERAutomation

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 4

WHITE PAPERStory 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. Di!erent teams estimate at di!erent 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 5

WHITE PAPER

The Agile Tester 6

WHITE PAPER

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.

ABOUT VERSIONONE

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

CONCLUSION

AUTHOR’S BIO