In modern times, it is common practice for developers to write unit tests with their code. This is a great thing. But developers aren't practiced at writing tests, nor do they have that base knowledge that your QA team would have.
Why not start learning from your QA team and getting them to share their subject matter expertise? Your QA folks have many years of experience in how to find bugs in software.
Just for fun (to prove this to yourself), the next time you bump into one of your testers in the hallway, ask them to list the standard / rule-of-thumb use-cases for boundary condition testing. I bet they come up with a few you didn't think about. They know a lot of cool stuff like that, stuff that you need to know to write effective unit tests.
There is a lot of good that comes from this.
The developers will start writing better unit tests. That means they find more of their own bugs, the ones that are easy for QA to find. This reduces cycle time and makes better use of the QA folks time.
The test team will feel good and valuable and loved because you are highlighting the fact that they have knowledge to share and you want to learn from them. This is not only a morale boost, but a culture shift as well.
Having more interaction between the test team and the dev team, outside of the "your app sucks" and "why didn't you find this bug" meetings, will enhance that relationship making for better and smoother interactions on projects which makes for better delivered product.