The building I work in is being redecorated and on the way to the canteen I noticed that the painters had covered a smoke detector with a rubber glove. You don't need to be a health and safety officer to realise that this is not standard policy and potentially risky.
But, paint fumes can set off smoke detectors and there were plenty of people around and there are many other smoke detectors in the building and the lack of other detectors covered with gloves suggested that decorators would be likely to remove it when they'd moved further down the building so I decided to do nothing about it. A clear spec violation, but mitigated by other factors. A reasonable short-term solution to an acute issue, but on the way home I still walked that way and checked that it had gone.
You'll sometimes hear testers described as pedantic and it's true that the detail and process-orientated aspects of our work are apt to be misinterpreted as (or can actually slide into) the rigid adherence to requirements.
It's not worth getting worked up about the term itself because, for example, to people who operate at helicopter altitudes on projects, the details are often just that, the details, the potential stains on the big picture and not their main focus or responsibility. And let's not kid ourselves. It works both ways and I'm sure you've got a few favoured adjectives for the teams you work with on a regular basis.
It is worth thinking about whether the description has some validity, and trying to demonstrate that it's not a fair blanket description of testers all the time. Look at yourself and wonder whether (a) now is the right forum and time for raising questions of detail; (b) whether any particular wrong you're concerned about really is not right given all the context or (c) whether despite being wrong it's also perhaps not not right for now and (d) whether you should monitor it and/or record the need to change it later, when it's more likely to be invalid and risky to have a spot fix buried in the codebase.