Make sure the new QA worker is aware of the potential for hostility. Often it's not recognized, the QA worker is demoralized, and doesn't know why. Expecting hostility won't reduce it, but will make it easier to deal with.

Don't be judgemental. If you see a lousy piece of code, don't say so. Design tests that will reveal its weaknesses - or discuss testing methods with the perpetrator. It's the end objective that counts.

Be aware of "face". Don't humiliate the programmers, no matter how much their code may deserve it.

Pass the buck. Don't critique the violation of coding standards and style. Point out the deficiencies and pass the buck to an amorphous, high-level, standards setter. "I'm just doing my job - it isn't my standards," etc.

Keep it private. Always try to get things accomplished within the private domain rather that the public domain. Try to get things improved without resorting to formal memos and deficiency reports.

Keep it light. You're dead serious but can't act that way. You can be a complete bastard and still smile.

Invoke a common enemy. Make the buyer's QA the common enemy if that suits. Invoke a government spec - divert the heat.

Give out rewards - acquire and develop test tools that will make the programmer's job easier. Provide feedback on the kinds of bugs and how to prevent them. Put out upbeat QA memos and reports when there's been a really successful project - praise the programmers for the quality and don't take public credit. Publish and distribute letters from satisfied buyers. Throw an acceptance party.

Help the project managers by giving them test progress feedback, bug projections, test completion reports, and anything else that will make their job easier and more predictable.