Their claims sound like hyperbole to me, but how can I know? They are the experts in testing! Am I really stuck with a choice between delivering late and delivering poor quality? How can I make the best decision for the project?
Establishing quality objectives is best done by looking back at prior projects. Did the last few projects produce systems that were of acceptable quality? Or did they fall short to some degree? These prior projects provide us with a basis for establish quality objectives for this one. If prior quality was judged to be sufficient, then we should probably plan to achieve the same quality levels this time.
On the other hand, if prior quality was judged to be insufficient, then we should plan to improve on it. How much improvement we want to make this time is a matter of judgment. While we might like to jump directly from "poor" to "perfect", we should be realistic in setting quality objectives, and plan for some incremental improvement (e.g. reducing delivered defect levels by 10% or 20%).
For example, if we spent 5% of the schedule on Peer Reviews and 30% of the schedule on testing, then in order to achieve the same level of quality, we should plan to spend those same percentages this time. If we spend less time on those quality-related activities this time, we should not be surprised if we produce poorer quality!
If we need to improve on our past quality performance, then we must plan to invest more time in the activities that will result in improved quality than we did in those prior projects. Does this mean that to achieve a 20% improvement in quality, we must spend 20% more time in testing? Unfortunately, it isn't that straightforward. There are actually a wide variety of investments we can make that will pay quality dividends.
How much more time should we allocate? This can only be determined by talking with the testers. What percentage of the planned tests ran successfully before release on those prior projects? If the number was in the 70%-80% range, then you were probably approaching stability when testing was stopped. In that case, a marginal increase in test time might be all that is required. But if only 50% or less of the tests had run successfully, then much more time is likely needed to reach the stability point.
But more testing is not our only option. There are other options that can improve the quality of the system before testing begins, thus allowing the same amount of testing (or maybe even less testing) to bring us to that stability point.
When a group first begins to do peer reviews, it is not unusual for them to find 40%-50% of the defects in the product during the reviews. Imaging that: half of the defects that might have been found during testing being fixed before testing even starts! And as your team becomes proficient in doing reviews, they are likely to find 60%-70% of the existing defects.
There is a tremendous amount of information about the effectiveness of reviews that has been published in magazines, books, research papers, and on the Internet. If you question their value, I recommend that you read about the results other companies have experienced.
Many projects don't focus enough on architectural analysis before the system is built. People make educated guesses about how it should be structured, and rely on assumptions about how the code they are writing will fit together with other parts of the system. When those assumptions or guesses turn out to be erroneous, the necessary rework often results in convoluted implementations that are prone to failure.
Although up-front design work is how most of us would approach this problem, the Agile methods (e.g. XP) prescribe a different approach: "Refactoring". Refactoring is essentially reworking the design after the fact. That is, when it becomes evident that the original structure is not working well, you stop and redesign the system or component, and then rework or replace the code to match that new design. Although Refactoring may sound wasteful, it is often a better spend of time than pressing forward with an ill-conceived design and fixing all of the problems that it causes.
Another way to prevent defects is by adopting coding standards that lead programmers to use sound practices and to avoid those that cause problems. Coding standards also make it easier for programmers to perform peer reviews of code, because they facilitate their ability to read and quickly understand each other's programs.
For example, if your testing is finding fewer than 40% of the existing defects, then you should be able to make it more effective (though exceeding 60% yield is uncommon for testing). Peer reviews can reach yields of 75%-80% after the team members have become proficient with them. If your review yields are below 60%, then you should look at improving them. If your reviews are resulting in fewer defects found and fixed than your testing, then there is clearly room to improve their efficiency!
In order to determine what you need to do to improve testing or reviews, you will have to look at how your practices differ from the industry best practices that have been abundantly published in the literature. Perhaps your team members could benefit from training to become more effective. Or maybe it is a matter of adjusting the procedures you use.
In the end, you will have a project that achieves its quality goals while staying within budget and schedule.