The tester should provide not only the screen shot(s) but the steps to reproduce the defect and the environment on which he is testing the application.
Also the tester should provide the screen shots of the requirements document which depicts the defect.
The best thing is to report the defect with all the details like the Environment on which tested, Browser details, DB details, Build number along with the test data.
When a defect is rejected
1. Go back and retest again to make sure that the defect is still existing.
2. If the Developer is in the same location show them how can he reproduce the issue
3. If the developer is in a different location, Capture the reproduction steps along with the screen shot (of UI and DB entries, XML request /response) and send the same to the developer so that the developer can reverify and fix the issue.
4. Some times issue can only be reproduced on the QA environment. In that case developer should be given access to QA env. so that they can see the log files for analysis.
At first it depends on a reason why developer rejected this deffect. And, of cource, on the processes :) I mean how the development process is organized.
Any way to avoid unnecessary questions, false rejects and not to loose the time I recommend:
1) When you post a bug provide the build version and environment where it was found;
2) Provide short description of a bug;
3) Then provide detailed steps how to reproduce it to be sure developer will be able to repeat them correctly.
If developer rejected a bug - then ask him by which reasons he rejected it and which build and environment he used for this.
If you cannot reproduce it yourself on the same build and env - close with a mark "retested, not reproduced".
If it reproduced - talk with developer, then reopen the issue and provide additional comment.
If it's not a bug - so close it with a mark "closed, not a bug".
1. Why the defect was rejected, due to poor documentation or could not able to reproduce. If not able to reproduce but it happened why was the log files were not verified. I should say defect raised will always has occurrence unless and until tester him self knows that defect was not valid
2. On what criteria defect was rejected.
3. Defect raised was due to out of box thinking, rational or logical thinking but still not mentioned on requirements.
4. Does BA joined discussion or issue was prior discussed then with some good information discussed with Dev team.
5. What were the comments provided when defects was rejected, does comments provide reasonable information.
And the list will go on, I would say if defect rejected where is the problem in tester or dev. Then we need to start digging to support issue reported.