The doubt or question i have is something every developer might be facing time to time.  it is related to testing and development team and their perspective.I have observed that most of the Defects which are getting logged are purely based on judgement rather than requirement. apart from that there is attitude that bugs which are getting logged has to be resolved which is causing lot of trouble and rework.What we as developer should do? How to tackle these scenarios?Approach which i have adopted so far is to reject the issues which are not as per the requirement.
Defects Review and Management
unit testing;manual testing
This sounds to me like a break-down of communication at a couple of levels. Since you've also not stated what your position in the project is, I'll assume that you're a regular dev who's working under an architect.Breakdown of WorkflowFirstly it sounds like there's not a properly defined way to handle bugs as they're entered into the tracking system. Someone has to rank them according to importance and then assign them to be fixed within budget and time-line constraints. Even basic bug-tracking systems have the ability to classify, rank and document various aspects of the issue. If you feel like these features could be used better, have a discussion with your architect or manager.Breakdown of TrustMore importantly, it seems like there's a little bit of defensiveness and mistrust of whoever your testers are. Understand that their role is to act as the user, so it might be better if they're not too bogged down with the details of the requirements specification. If they're raising bugs for you, don't immediately assume that they haven't understood the requirements well enough; try and drill down into what exactly they were trying to do and why they landed at that use-case.Also if it's something that keeps coming up then there might be something that wasn't properly defined in the requirements.SummaryAll in all, just understand that you and the testers are on the same team and that you'll are both just trying to make a better product for the user. After all, customers aren't going to get your requirements document; either the thing works or it doesn't.