The Ruby language has gained many followers recently. Ruby offers many of the same features that made Perl a popular scripting language, but also has the advantage of being a fully object-oriented language. While developing an object-oriented application in Perl might be a bit clumsy, Ruby supports object-oriented programming quite naturally. This can offer many advantages when developing a large testing application.

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.