CONTENTS Executive Summary ................................... ....................................................................... ..................................................1 ..............1
Introduction................................. Introduction ..................................................................... ....................................................................1 ................................1
Traditional Tra ditional QA .................................. ...................................................................... ..............................................................1 ..........................1
Agile Testing Explained ............................................................................ .............................................................................2 .2
New Skills or the Agile Tester Tester ................................ ...............................................................2 ...............................2
The Tester and the Team ........................................................ ...........................................................................3 ...................3
Conclusion ................................... ....................................................................... ...................................................................6 ...............................6
A mature QA process serves an important purpose, one which must be retained in the transition to agile.
In addition, business requirements oten change ater test
tester on the agile team provides early eedback during all
cases are developed, requiring extensive test case re-
stages o development, helps or is cognizant o code-level
writes and test plan changes, i the requirement changes
testing being perormed, takes the lead on acceptance
are communicated to both development and QA. I
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 dierent expectations o the nal product. In addition, the agile tester ensures acceptance test As test case automation has become increasingly
coverage is adequate, leads automation eorts on
important, QA teams have had to incorporate another
integrated, system-level tests, keeps test environments
signicant activity into the workfow. Larger organizations
and data available, identies 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.
perormance and regression testing, that alls outside the
This adds another layer o required communication to an
scope o story-level testing, can be addressed through
already signicant load.
test-oriented stories, which are estimated, planned and tracked just like a product-oriented story.
Finally, since QA is usually the last activity beore a xed release date, many planned QA activities may get
NEW SKILLS FOR THE AGILE TESTER
squeezed rom the schedule, compromising product quality.
Transitioning rom a QA Engineer to an agile tester means more than a change in when the product is tested and
AGILE TESTING EXPLAINED
how much o it is tested at a time. There’s a new paradigm or the agile tester — instead o be ing the Quality Police,
Agile testing ollows a more fuid, 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 shit a bit easier.
all o the requirements work or a system, then all o the development work and then all o the testing work
Team Member
consecutively. Instead, the agile team takes a small piece o the system and works together to complete that piece
The agile tester is a ull-fedged, rst-class member o
o the system. The piece may be inrastructure-related,
the agile team. The agile tester participates in planning,
eature 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 thoughtul, analytical
The project marches toward completion piece by piece.
problem solvers and oten add a unique perspective to the team in terms o identiying potential road blocks
Completing a piece o the system, reerred to as a story
and dependencies early in the process. Testers need to
or backlog item, means that product management,
participate as members o the agile team, not just the QA
development and testing work together toward a
team, to bring this inormation to the team’s attention as
common goal. The goal is or the story to be ‘done.’
soon as possible.
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 agrees on nal acceptance criteria or a story to determine when it’s ‘done’.
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
During an iteration, several stories may be in various
additional considerations or the product owner to
stages o development, test, or acceptance. Agile
evaluate. James Bach, Cem Kamer and other members o
testing is continuous, since everyone on an agile team
the agile testing community have contributed numerous
tests. However, both the ocus and timing o testing is
excellent publications on exploratory testing techniques.
dierent depending on what type o testing is perormed. Developers take the lead on code-level tests, while the
Automation Agile emphasizes automating as much as possible. Agile works best with some level o 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 o end-to-end and scenario testing results. Automation is not a s eparate project or a tester-only activity and it’s not just test case automation: is part o the story delivery process. Automation is anything that allows the team to work aster 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 or test cases and don’t get three months to write test cases beore they see a working piece o code. They jump into the communication stream, which may be verbal, written, or virtual and assimilate the inormation they need. They learn to ask the right questions at the right time and provide the right level o eedback at the right time.
THE TESTER AND THE TEAM A single story walkthrough demonstrates what an agile tester does as part o an agile team. Here’s a simple story that might be presented to an agile team: An agile tester will contribute to the team rom the time the story is presented to the team to when it’s completed, not just during testing. Let’s look at specic contributions during these phases o work: •
Story Exploration
•
Estimation
•
Story Planning
•
Story Progression
•
Story Acceptance
Story Exploration A story does not magically appear. There’s 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 bee n 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 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 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 e mail address to be ‘unknown’?
•
What does it mean to ‘require conrmation’ o 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 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’ the story 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 release planning. 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.
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
