I can only tell you what I do. First, if you see a bug then it's "your fault" and you should enter it into the tracker, write a test case proving the bug, fix it, and submit the fix. If the QA teams sees a but then it's "their fault" and should be entered in the tracker with steps to reproduce.
Now it's not really about fault, it's more about long term responsibility. When you do a meeting to talk about progress, who is going to be "boss of that bug". The best answer is usually the one that finds it. Meaning that the team putting in the bug is the one that needs to be going "did you fix X yet".
Even more important is the fact that not every bug is going to be fixed. In the real world you have to manage bugs v.s. time constraints and other costs. It's "ok" to have a bug that's not going to get fixed in the next version, as long as everyone knows where it is, and there's a clear expectation of when it will be fixed.
So, first if you see a bug enter it into the tracker. Handle accordingly. A documented bug is 1000 times better then an undocumented one.
Now as for telling the QA team to do stuff. I personally think it's none of my business what the QA team does. As long as they find bugs and get them into the tracker in a agreed upon format, then I'm good. By having that separation I feel that I maximize their usefulness (finding "bugs" that arise, not because code faults, but because of mis-understandings). If I am giving work direction then I feel like I am not letting them do what they need to do. As have even gone as far as refusing to help them do something in the app so that we could see if the stuff they needed to do to accomplish their task was intuitive enough.
Finally, depending on company structure, you shouldn't be telling QA to do anything. Do they report to you? Do you sign their pay check. More often then not QA is equal to Dev in the corporate ladder. Telling someone to do more work is definitely not your job (unless it is). That does not mean you don't work closely with QA, you should be. At the same time, there not part of "your team" so hands off.
Most importantly from all this is:
- If you find a bug, enter it, and handle it. Don't ask others to
- Don't give work direction to other teams, it's not your place
Remember, this is very different company to company. This closely matches "what I do". But different companies will do things differently. You should either use their SOP or work with them to develop a SOP document.
I also stayed away from management, organization, or planing techniques. There are a lot of questions answered if you adopt one technique or another.