Professional Documents
Culture Documents
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
WHITE PAPER
In addition, business requirements often change after test cases are developed, requiring extensive test case rewrites and test plan changes, if the requirement changes are communicated to both development and QA. If requirement changes arent communicated consistently, theres 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. 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.
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 its 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 dont get a big requirements document as a basis for test cases and dont 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.
WHITE PAPER
Story Exploration A story does not magically appear. Theres 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 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 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. Its expected that there will be some unknowns in the system at this point and theres 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.
WHITE PAPER
WHITE PAPER
CONCLUSION
AUTHORS 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