About a year ago, Ray Arell called his software staff together and declared, "Hey! We are going agile!" Ray read an agile project management book on a long flight to India, and, like all good reactionary development managers, he was sold! Now-two years later-their agile/Scrum process has taken shape; however, its adoption was not without strain on development, test, and other QA practices. Join Ray as he takes you on a retrospective of what went right and, more importantly, what went wrong as they evolved to a new development/test process. He introduces the software validation strategies developed and adapted for Scrum, explains what makes up a flexible validation plan, and discusses their iterative test method. Learn how they use customer personas to help test teams understand expectations for quality in each sprint and employ exploratory testing in the Scrum development flow.

Manual testing is the best way to find the bugs most likely to bite users badly after a product ships. However, manual testing remains a very ad hoc, aimless process. At a number of companies across the globe, groups of test innovators gathered in think tank settings to create a better way to do manual testing—a way that is more prescriptive, repeatable, and capable of finding the highest quality bugs. The result is a new methodology for exploratory testing based on the concept of tours through the application under test. In short, tours represent a more purposeful way to plan and execute exploratory tests. James Whittaker describes the tourist metaphor for this novel approach and demonstrates tours taken by test teams from various companies including Microsoft and Google. He presents results from numerous projects where the tours were used in critical-path production environments.

Although organizations have vastly increased their efforts to secure operating systems and networks from attackers, most have neglected the security of their applications-making them the weakest link in their overall security chain. By some industry estimates, 75 percent of security attacks now focus on the application layer. All too often, the departmental responsibility for verifying application security is not defined, and security within the SDLC is either addressed too late or not at all. Based on his experience in a Fortune 1000 company, Mike Hryekewicz describes a step-wise strategy for extending the QA department’s role to include security as a quality attribute to verify prior to an application going into production. Learn how to deploy a security testing capability within your QA department and how to extend its coverage and activities as the process gains acceptance.

Static analysis is a technique for finding defects in code without executing it. Static analysis tools are easy to use because no test cases or manual code reviews are needed. Static analysis technology has advanced significantly in the past few years. Although the use of this technique is increasing, many misconceptions still exist about the capabilities of advanced static analysis tools. Paul Anderson describes the latest breed of static analysis tools, explains how they work, and clarifies their strengths and limitations. He demystifies static analysis jargon-terms such as object-sensitive, context-sensitive, and others. Paul describes how best to use static analysis tools in the software life cycle and how these can make traditional testing activities more effective. Paul presents data from real case studies to demonstrate the usage and effectiveness of these tools in practice.