I’ve seen project task lists in which the author assumed that every testing experience will be a success that lets you move into the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. Base your estimates of rework time on previous experience. For example, you might have historical inspection data indicating that, on average, your developers find 25 defects per thousand lines of code by inspection and that it costs an average of 40 minutes to fully repair each code defect. You can crunch these kinds of numbers to come up with average expected rework effort for various types of work products. If you don’t actually have to do any rework after a test, great; you’re ahead of schedule on that task. Don’t count on it, though.
Adapted from “Practical Project Initiation: A Handbook with Tools” (Microsoft Press, 2007). A condensed version of this paper was published in Software Development magazine.
Karl Wiegers, Ph.D., is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. Karl’s most recent book is “Practical Project Initiation: A Handbook with Tools.” Karl is also the author of four other books and 170 articles. Karl is a frequent speaker at software conferences and professional society meetings. You can reach Karl through www.projectinitiation.com or www.processimpact.com.