Manage the Risks and the Process

accumulation of several slips in the schedule do they begin to pay attention. The earliest slips, though, should be taken as early warning signs.

The test team needs to address promptly why the project is slipping, and resolve the problem. The idea is to monitor both the preventive QA efforts and the test efforts carefully to determine when they are falling behind, and to take quick corrective actions.

Of course, these comments assume that we know we are slipping in the first place. If the project objectives and scope are imprecise, or if there is not a reasonably detailed workplan with scheduled milestones, there is no way to detect the slippage.

Predict and track the likely causes of delay. Once a week on the testing project, take the time to look ahead and identify the likely causes of delay over the next two, three, and four weeks. Keep a close eye on these.

Aggressively manage defect aging. Set turnaround goals for the resolution of reported problems, based on levels of severity; e.g., showstoppers should be fixed and ready for retesting within twenty-four hours. Monitor the level of compliance with these goals.

Have an early warning process to identify test bottlenecks and resolve them quickly. Vigorously monitor defect aging, as mentioned earlier: this is a major cause of temporary blockages in testing.

Testing is often delayed for the most mundane of reasons, which attention to detail and smart test project management can avoid. Seemingly trivial and senseless reasons for delays include not having the test environment ready on time, having testers who have never formally been trained to use the automated test tools they are using, and "tiny" last-minute improvements by developers who cannot leave well enough alone. The list could go on and on.

Measure how time is being used. The first step in the management of an individual's time or a team's time is to understand where the hours are being spent. For example, a Bell Labs study found that software engineers spent only thirteen percent of their days on actual programming tasks. The remainder of the time was frittered away on other activities, such as interruptions, unscheduled meetings, phone calls, and tasks unrelated to meeting the deadline.

Be proactive, not passive. Don't procrastinate and "go with the flow" before you raise concerns. Often, the politics of projects cause the testers to be fairly low in the pecking order, and it is easy for the testers to be passive and take their direction from developers or others, rather than taking the initiative themselves. While there is a danger of going too far when testers may not be aware of certain business reasons for a delay, a strong and independent test team can speed the delivery process.

Don't allow interpersonal conflict to get in the way. There is often "bad blood" between the developers and the testers, or at least an unwillingness to cooperate, an inability to see each other's point of view, or miscommunication. Ultimately, we are all in the same boat-we win or lose together. Working effectively with developers, users, and managers does not mean that a tester has to compromise quality principles.

Don't allow a crisis to derail the project. It is an unusual project that does not have at least one crisis or major hassle sooner or later. It is how we handle the crisis that counts. Crises are miserable-there may be finger pointing and recriminations, high stress, screaming, and exhausting long hours until the crisis is resolved.

With motivation, teamwork, and trust, the team will get through the crisis. Without these, everything can fall apart.