Manage and Strengthen Testing

the testing schedule.

Manage the critical path. When any task on the critical path slips, he entire test project slips. This requires, of course, that we know what the ritical path is (and it can change frequently, as events change).

Coordinate closely with other groups. Most vendor software and eb-based development projects today utilize so-called RAD (rapid application evelopment) methods such as XP (extreme programming) and agile methods. To be ffective, RAD requires a more fine-tuned coordination of testers with others, uch as developers, Web site content managers, users, and marketers in a vendor rganization, than is needed with traditional system development methodologies.

Manage the interdependencies among activities. More than mere oordination is needed on most projects-the interactions among the o-dependent parties must be proactively planned and managed. Development and esting projects usually have many mutual dependencies among their internal asks, and more-difficult-to-manage dependencies with tasks external to the roject. We may even have gridlock: person A may be dependent and waiting on erson B, who is waiting on person C, who in turn awaits some deliverable from erson A.

Managing the interdependencies means that we first know what they are, and ave up-to-date information on the status of predecessor tasks. The test and QA ilestones should be included in the overall system development project chedule, and coordinated with the other project activities (design, rogramming, etc.).

Balance the test resources to the workload demands. Plan ahead: aintain a forward-looking calendar of the major systems and new versions lanned for the next eight to sixteen weeks, and their likely demands on the esting resources. Schedule and allocate test and QA resources for these evelopment projects, especially to provide early preventive QA.

Use project management tools. Realistically, test planning, cheduling, monitoring, and updating test project plans cannot be done without a ood project management tool, such as Microsoft Project. These tools facilitate ore sophisticated modeling and exploration of alternative courses of action, by llowing rapid iterations of planning scenarios and by using "what f?" sensitivity analysis.

However, the majority-perhaps 85 percent-of test professionals do not use roject management tools. They use informal devices like paper lists of tasks nstead (the "back of the envelope"), and manage by the seats of their ants.

Manage expectations. Sometimes the test function is blamed for late elivery, because the testing occurs at the end of the delivery cycle; herefore, it is conspicuous as the reason why the system is not yet ready. eople will say, "It takes too long to test!" Educate managers and lients by presenting status information on when a system was actually ready to est, how many defects have been found during the test, and what effort is equired for an adequate test.

2. Strengthen the Test Resources

Add test resources. Many test efforts today are under-resourced, artly because of optimism, denial, and lack of understanding of what is needed o perform an adequate test. Many managers and professionals are surprised by he amount of testing indicated by time-proven test estimating formulae, and rankly do not believe them. However, we have considerable evidence that these ules of thumb are about right, from actual projects in leading software rganizations. Many software vendors, for example, have a ratio of software ngineers to testers of 3:1 or 2:1.

Resist the temptation to add people resources to a late project. espite the suggestion above to add resources, Brook's law states that adding eople to a late project only makes it later. If the newly added resources join he test effort too late, or the newcomers are not experienced and already riented to the project, Brook's law will