Respect the time requirement for QA
All to often, test time becomes the project buffer time. If the release candidate is a day late, do you shift the release date or do you tell the QA folk to test faster or to test less?
Keep them it the loop if it looks as if there might be a delay.
Give the testers recognition (like bonuses, promotions, ...) if they run their tests fast and effectively despite the late delivery of the release candidate. (As a side note, don't reward them for the number of bug reports.)
Inform them what your unit tests cover and how
When the QA people have reviewed your unit tests and seen the most recent protocols, they can avoid duplication of effort (unless there is a deliberate decision to double-check). The testers can concentrate on things which automated tests are less likely to catch.
Let them see and challenge the original specifications/stories
QA professionals are trained to see edge cases and failures where developers want to make things work. Let them write most of their test cases and show them to the developer before the first line of code is written. (Test Driven Development, TDD)
I've once been in a project where a tester rejected the specification as buggy. The tester was right, the spec wasn't consistent with a previous requirement.
Consider if the QA should be a separate team or part of the dev team
There are good reasons for both. If the project is waterfall-like and documentation of compliance is important, make the QA a separate team with a team lead at the same level as the development team lead. If the project is agile and documentation of tests is less important, put the testers into the dev team. If using scrum, write passed tests into the definition of done. The story isn't finished until the tests are finished.
In the most extreme case, that could mean abolishing testers. Every developer is responsible for quality.