A developer turned tester doesn’t want you to be a “net negative producing tester” and says:
It wasn’t only poor bug reports that wasted time. The majority of the bug reports were low-hanging fruit ones, easy to find ( and fix ) but trivial in nature – tabbing order, buttons misaligned etc. There was no bug triage in place to sort them into priority order so it meant either reading through the entire bug list to find the severe ones – or most commonly just starting with the first on the list and working through it
The result – lots of time spent fixing minor bugs and the customer finding the severe ones.
Where have I heard that sort of argument before? Oh, yeah, pretty much any time a development lead, project manager, or customer-facing person tells us to do the same thing, ignoring the obvious issues and only logging the important ones. And my response is always the same: ever the professional, I do not preface my “No” with any colorful metaphors.
You have to log all defects against an application. Cosmetic things might be “low-hanging fruit” to a developer, but those cosmetic failures and misspellings in labels and poorly-written error messages destroy a user’s trust in the application. If they’re wrong, they should be fixed.
Failures in prioritization and the fact that your developers are knobs who would rather spend 4 hours “fixing” a couple of misspellings or tab order things (read: 20 minutes in the IDE, 3 hours at the foosball table) are different problems.
So make sure the misspellings and whatnot are prioritized low in a defect tracker and browbeat your developers into handling fundamental business logic failures. Somewhere along the line, your organization is going to have to bring in new people, and these simple defects offer them a chance to get their feet wet in the code.
But telling testers not to log defects isn’t the answer.
To sum up, our philosophy here at QAHY is to be a net negative tester. The more negative you net, the better, regardless of what the opposition would try to make you believe.