In my firm, we don't have testers, exactly. We have analysts who translate business requirements into specifications. (Think the guy from Office Space, except these guys actually provide some value. Kind of.) Because they have an agenda (keeping the people who gave them the requirements happy) they are often lacking in the thoroughness of the testing they do. Sometimes it's because they simply hadn't considered one portion, but sometimes it's where they actively ignore an area because they know if they test it, it will break, or if they test it they wouldn't know right or wrong either way.
The kicker is, a month from now, I might get a spec that fixes "a bug introduced with project 12345." Well, gosh, I sure did a lot of testing on that, obviously I missed some of it. Now, the development team is the one who takes the flak because they're the one who introduced the bug. I for one am willing to admit I don't write perfect code, and so are people on my team. But how do you deal with a (biased) testing group that 1) doesn't communicate with other testers, and 2) refuses to accept the fact they also missed it in their testing?
Keep in mind that this is a highly un-idealistic environment. There are some of us who have had it quite good in the past, and would like to bring our department up to speed on best practices. It's a slow process, and sometimes we're not sure even where to start.