Section 1.3. Review Everything, Test Everything

1.3. Review Everything, Test Everything

Reviews get a bad rap. Many people see them as frivolous. "In a perfect world," many project managers say, "we would review all of our documents. But we live in the real world, and we just don't have time." Others feel that the only reason for a review is to force various people to sign off on a documentas if a signature on a page somehow guarantees that they agree with everything that it's stapled to.

The purpose of a review is not to make a perfect document or to generate a page of signatures. Rather, a review does two things: it prevents defects in the software and it helps the project manager gain a real, informed commitment from the team. What's more, it's important to recognize that no review is perfectand that's just fine. It may not be possible to catch 100% of the defects before coding has started, but a good review will catch enough defects to more than pay for the time it took to hold the review.

It is always faster and cheaper to hold a review meeting than it is to skip it, simply because it's much easier to fix something on paper than it is to build it first and fix it later. When a review turns up an error that takes a few minutes to fix in a document, it saves the team the hours, days, or weeks that it would take to fix the error once it has been built into the software. But even more importantly, reviews frequently uncover errors in documents whose resolution requires a lot of discussion and decision-making. Errors like this can completely destroy a software project if they make it all the way into the code.

Many project managers try to schedule reviews, only to meet with an enormous amount of resistance from everyone around them. Peers, project team members, and senior managers all seem to resist the idea of "yet another meeting." Oddly, the same project managers who are unable to scrape together an hour and a half to review a scope document at the beginning of the project generally have no difficulty whatsoever scheduling lengthy, tedious weekly status meetings with no agenda, goal, or purpose. (Of course, not all project status meetings have to be run that way!)

The truth is that there is no such thing as wasted time in a review. On average, every hour spent reviewing and repairing documents saves well over an hour later in the project. This is true because it catches costly errors early on in the project, when they are cheap to fix. But reviews have other valuable benefits as well. By bringing team members into a room to evaluate each others' work, reviews foster respect among the team members for everyone's contributions. And, most importantly, a review results in a real commitment to the work that is produced by the team, not just a signature.

Testingwhether it is unit testing, functional testing, performance testing or regression testingis just as important, and just as likely to be dismissed as unaffordable or "idealistic." Yet software testing activities are just as cost-effective as reviews. The team can't "test in" quality at the end of a project just by tacking on some testing tasks. Testing must be planned from the beginning and then supported throughout the entire project. To come up with a quality product, the entire team needs to actively look for defects at every stage, in every document, and in the software. It's the project manager's responsibility to make sure that this happens.