First of all, explain him 'Why do you think it is bug". (I wont call it a bug but rather 'Application behavior').
Not every behavior THAT YOU THINK is a bug is a bug. First thing to convince the developer is to stop finger point. Bug is not HIS FAULT. Try co-operation not allegation. As soon as you say 'Hey! you have done something wrong' he may felt offended. Instead you can 'hey! I am observing this behavior which seems incorrect'..
OK, Not going into psychological section. lets proceed
- Is application behavior not as per the requirements?. In such a case, it is simple to ask developer to follow the requirement document.
Note that it may be possible that requirement document has not covered 'this' particular use case. Normally the case that you have mentioned is the case of uncovered requirement or conflicting requirement and in such a case you must see the big picture. At broader level, What user problem that particular feature (that you are testing) is going to solve. If the current behavior is not assisting in the solution but at same time makes the things worse then it is bug. Then you need to convince, how that particular behaviour can be blocking or disturbing to user intent.
I agreed with all reply
but same question was asked me in Rave technology.
I had given the same reply as given by you guys
Interviewer asked me "Still the developer is not accepting then what will u do"
And i replied i will mail him keeping BA,TL and manager in loop" and in mail i will focus the impact or the importance of the bug in terms of functionality.
We are a testers our work is detection of defect.i did my job very well and i had informed all the authorites in a loop.now ball is in there court, if the bug reproduce in production then its not mine mistake though i already
In many cases the project manager assigns the bug to devs and specially in situation where developer does not accept the bug. So you have to make sure that also manager side undestands the bug. Usually when I'm submitting questionable bug, I have two parts at report. First part is more technical which describes how to reproduce the bug, "hard evidences" like screenshots or log snippets. And second part is story how it impacts to real users. More detailed description about story telling is at my blog.