Jason Cohen of Smart Bear Software has a brilliant blog. His post on QA vs. QC is something I've talked about in the past. I love his example of the Pringles manufacturing line discarding off-color chips -- it's a concrete, understandable way to define the difference between QA and QC.

Some of my best project experiences have been those that have involved the testers starting at the requirements phase. These guys have a different attitude and have asked some great questions that prevented us from going down dead-ends.

Great testers find and isolate really hairy bugs. Truly great testers not only find these bugs, but will often find a pattern of bugs and can, for example, point to the portion of the spec that the code failed to implement. They take a bigger picture view of the product and its environment and how to improve the quality by both preventing defects and figuring out how to detect defects during the test phase.

As Jason says, we should let these guys have a little more influence on the development process. For example, they should be insisting on design and code reviews, even if they don't participate. Because when the development team is in solely in charge of the development process, these steps sometimes get skipped -- because the job is a rush, or because the feature is small and doesn't need to be reviewed. (Even though rush jobs are most in need of reviews, and small features always seem to take longer because they receive less care and attention.)