In teams where I've worked closely with the testers, we've gotten along fantastically. Testers understand the decisions that went into various decisions made, they know what the dev's schedules are like, and a rapport is built between the two groups.
In teams where test is some amorphous entity offshore, this has not been the case. The testers' results are less relevant because they don't know as much about what's going on, the devs begin to dread the flood of what they consider to be inconsequential details that are in parts of the program that haven't been touched in two months, the test team gets annoyed that none of the filed bugs are being fixed (because the schedule is screwed up and the devs are busy getting ready for demos or adding requested features, etc), and in general both groups see each other as antagonistic "others" as opposed to team members.
Work closely and things will be fine. Somebody needs to make sure both teams are coordinated and on the same page. My best experience, the test team was invited to any high level meeting the dev team was invited to (all of them) and we all knew the schedule, we had a unified priority list, and devs and test both had the same (up-to-date) requirements document. My worst experience (other than no test) we basically packaged up our stuff, shipped it overseas to be looked at, then got everything back a month later with things marked as wrong that weren't even ours (3rd party plugin that met the new requirements, but not the test team's expectations).
Neither dev or test will succeed without the other. If you work like two halves of the same machine and respect the other side as much as you respect your more immediate team members, things will be fine. Behave like two separate machines and assume your machine is better, things will be terrible.