As a guy in QA, what should I do? I can't ever tell if it's just the developer being nice when they say they want me to tell them about bugs before filing them, or if they actually want me to.
How would you want your QA people to deal with this problem?
File a ticket. I will generally be nice when people interrupt me due to bugs or issues, but in most cases I will also be annoyed because I am busy working on something and now I am out of the flow.
File a ticket, I will get to it the next time I am in the tracker updating my task list or jotting down the time it took me to do certain things. Anything from QA coming back to me requires my immediate attention because most likely I am holding someone or something up.
See, that's part of the problem. We need to interact with you. Do we skip meetings and go to tickets? Except that tickets are often ignored or are misunderstood. Then comes the need for discussion. Of course, interrupting a developer is bad, so you have to schedule a discussion - A.K.A a meeting.
What I notice at my current employer is that trying to avoid pulling people into meetings results in what I call "Development by game of Telephone", where software requirements become rumors passed between employees. (Even when requirements are documented -- because the documentation is vague.)
If you have to file a ticket every time you need to ask someone a question about work, you will find that the lack of coordination will make whatever your team is working on fail, so you should just fire the developer who requires that and save his salary.
Usually there's a question of, "Is this a bug, or do we have an environment problem, or configuration problem, or is it really a feature?"
In a perfect world, environments would be exact, configs would never change, and features would be flawlessly documented, but such a world is not one I live in, nor do many other people.
How would you want your QA people to deal with this problem?