First of all, we should mention the severity of the bug. 
Then try to explain to developer, how much the bug effects 
the functionality. No matter what the developer says, if it 
is bug, report it. Isn't it simple.

Before raising any bug, first try to understand and analyze 
it from requirement of view.

Do not come to conclusion that it is a software bug 
instantaneious if you are not getting the expected result 
in the application.  It can be a test case or test data bug 
meaning that the application is working fine but the 
expected result in the test case itself is wrong. It could 
be your misinterpreation of the requirement.

Hence, analyze it and come to conclusion that it is really 
a bug as it is not adhering to the requirement, RAISE it.

When we found bug we will review it internally
we will report the bug in bug tracking system with detail 
steps including screen shots and procedure
we will also consult with the developera and shows the 
procedure 
we will also go through functional documents to amke sure 
that it is bug

If still debate occurs we will raise it in Bug triage 
Meetings

i will try to reproduce the defect by re-engineering 
testcase and take the snapshots of all screen. now i will 
post to developer with strong reasongs along with snap / 
screen shots

jay,
IBM

Hi,

  If u found a Defect, but the Developer says it is not a 
defect then u can send the snap shots of the particular 
scenatio from starting to ending .. by using the snap shots 
the developer can understand wht test data that the tester 
has given..

When a developer say it is not defect.  Then, ask the 
developer to give a complete and proper justification note 
to that effect.  Then, if found that developer has mis-
understood the requirements/reproduction steps given in bug 
report then convice him about his mistake.  
In short if tester is sure that it is really a defect then 
challenge the developer in a healthy manner.

With due respect to all the above answers, at times this 
situation arrives where developer says application is as 
per requirement. 
At the same time not all requirements will be documented in 
BRD. As a tester when u come across a defect which is 
directly not pointing to requirement but at the same time 
can be critical from business point of view.

This is where the conflict can arise between dev & tester. 
In this situation, tester can discuss the issue with 
business analyst [who acts as bridge between project team & 
client] & after clarification, project the defect to dev 
team with more clarity and thereby convincing dev team in 
accepting the observation.