Traditional methods for improving testing include training, hiring, adding new processes, building infrastructure, and buying new tools. But what about increasing the capability of the team? Author Aldous Huxley said, "Experience is not what happens to a man; it is what a man does with what happens to him." The same is true for software teams: It's what we do with our experience that matters. Too often, we don't do much-if anything-to squeeze learning out of our experience. Retrospectives are a way to take the "what happened" during a software project and use it to build understanding. Testing borrows a page from adult learning theory and project reviews to increase team capability through Testing Retrospectives, and determines how to do more of what worked and less of what didn't.

It's impossible to test everything-even in the most trivial of systems. Tight time schedules and shortages of trained testing personnel exacerbate this problem; so do changing priorities, feature creep, and loss of resources. In many companies, test professionals either begin their work on whichever components they encounter first, or the parts they're most familiar with. Unfortunately, these approaches may result in the delivery of a system where the most critical components remain untested. Or, at the very least, critical components are tested later in the lifecycle when there may not be time to fix the problems found. All of this adds to the risk of a project. One way to overcome every one of these challenges is to employ the use of risk analysis. Rick Craig demonstrates the basics of a usable process for assigning testing priorities based on relative risk.

More often than not, even modest software test automation efforts fail to achieve their goals. Usually these project shortcomings happen because the introduction of test automation reduces the effectiveness of the test group, thereby reducing the number of tests and the number and complexity of product defects found. Several common misconceptions about the value and techniques for software test automation contribute to this problem. Douglas Hoffman explores some of the more common issues and addresses how to recognize and avoid them. He delves into each blind alley, describing each one and showing you how and why they sometimes lead to failure. He then offers you strategies for understanding and avoiding them.

Three years ago, Christopher DeNardis embarked on a career as a software tester. After just one year of testing, he was promoted to leader of the test group. In this session, he shows you the four keys to getting through those times and becoming better organized as a test manager: 1. a common set of ground rules on the test progress, defect reporting, and verification; 2. the ability to convey how your team's testing is going on a frequent basis; 3. knowing what needs to be tested and being able to stand behind the reasons why; and 4. maintaining good communication with the development leaders to help move the product through the development phases.