Use Defect-Tracking Systems Effectively
More than likely, your project team uses some form of automated defect-tracking or bug-tracking system. Developers should tell testers what specific information in a defect ticket is most helpful to each developer. When entering a defect, testers should provide the right type and amount of information: Attach a screenshot, source code, steps taken or a script/test case that can reproduce the bug, and any relevant log files. Try not to include suggestions about what might be the problem; you may be wrong, and including your conclusions may make the developer feel as if you don't think he or she can figure out the problem. Have long or complex bug reports reviewed by a second person to ensure that the information is clear. (I prefer to get feedback from another tester first, rather than get negative feedback from a developer who's missing some piece of information and, because of that, thinks of me as incompetent.)
Before assigning priority to defects, testers and developers should work out a prioritization scheme. When more pressing defects need attention, developers get annoyed by lots of reports of little problems that the customer is unlikely to encounter. If defects aren't prioritized properly, developers may also ignore or miss serious problems while sorting through less-significant defects. By prioritizing the issues, you ensure that critical bugs get fixed immediately and small problems get attention when time is available.
If you're a tester, and you have a problem getting your point across using the bug-tracking tool, go and talk with the developer if at all possible. If he or she is within walking distance, start walking. If you're in different locations, use the phone. If you're in different time zones, schedule a regular time to interface with the developer every week or so (she comes in early and you stay late, or something comparable).
While defect-tracking or bug-tracking tools are great for organizing issues and managing what goes into each release, by removing face-to-face contact they can become a barrier to communication between developers and testers. However necessary these tools may be, it's important that we understand that such tools are not a substitute for more effective means of communication.