After my most recent conversation with my Manager (not QA Manager) I was told that it would be a good idea to look at defects coming from users to help out developers and save their time, by possibly closing something that are not defects, or narrowing down some issues.
I have never looked at defects before they were not assigned to QA with any status. Does anyone thinks from QA point of view it is right process and if so may be why? I do believe that developers should address issues first by either rejecting them or fixing. Any thoughts
Depends on your company's procedures. For our Beta products, we in test get the job of identifying and writing up bugs reported by the beta testers. For released products, any bugs come to us from Tech Support, and only then if they are not already documented. In that case we investigate, try to reproduce and, if successful, log the bug (and try to find a work-around to give the tech support guy to pass on to the customer).
The process in my company is for User defects to be submitted to QA before they go to the developers. It is a chance to identify what the business is reporting and categorize. QA will verify and add details to provide the developers with more information. Items that are out of scope can be recognized and assigned to the project manager for discussion and possibly change control. Duplicates are recognized and dealt with.
This allows the developers to have more time to spend on the real defects.
It also provides testers with an insight as to what a business customer is looking at for their future testing projects.
I agree with your manager.
I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison