Although test managers are tasked with helping manage project risks, risk management practices used on most software projects produce only an illusion of safety. Many software development risks cannot be managed because they are unknown, unquantifiable, uncontrollable, or unmentionable. Rather than planning only for risks that have previously occurred, project and test managers must begin with the assumption that something new will impact their project. The secret to effective risk management is to create mechanisms that provide for the early detection and quick response to such events--not simply to create checklists of problems you've previously seen. Pete McBreen presents risk "insurance" as a better alternative to classic risk management.

Our testing is only as good as our thinking—and all too often we are hampered by limiting ideas, poor communication, and pre-set roles and responsibilities. Based on the work of Edward de Bono, the Six Thinking Hats for software testers have helped Julian, and numerous others, work more effectively as testers and managers. The concepts are simple and easy to learn. For instance, we can use these concepts as individuals performing reviews and while testing and in groups during team meetings. Each of the six hats has a color representing a direction of thinking—the blue hat provides the overview and helps to keep us productive, the white hat helps us to collect facts, the red is a way to express intuition and feelings without having to justify them, the yellow hat seeks the best possible outcome, the black hat helps us to discover what might go wrong—not only with the software but also with our tests and our assumptions!

Test managers often choose solutions to problems without sufficient analysis, resulting in a cover-up of the symptom rather than a solution to the underlying problem. Later, the problem may surface again in a different disguise, and we may mishandle it again, just as we did initially. Alon Linetzki describes a simple process you can use to identify the root causes of problems and create an appropriate solution to eliminate them. Alon shows how he enhanced the classic root cause analysis method to create an approach to finding insidious problems in software and processes. His method includes ways to differentiate symptoms from problems, understand the connection between them, and determine the strength and direction of that connection. Alon illustrates this method with data from two testing projects and shares the lessons learned along the way.

As software testers, we are regularly asked how long it will take to test a system. Unfortunately, we rarely have the tools to produce an accurate estimate. Tonnvane Wiswell introduces methods for producing better estimates-best guess, experienced person's best guess, and ways to use past data as a baseline--and the advantages and disadvantages of each. She discusses adaptable formulas that incorporate "buffer time" and risk factors. Finally, Tonnvane presents a real life example of a testing project with solid time estimates, including an explanation of how team size was determined, how the work flow was designed, what the "actual hours" of testing were, what unexpected items affected the testing time, and how the project permanently changed the company's "test estimation formula."

• Two simple estimations methods when you don't have historical data
• How to improve test estimation in your organization