Well…yes. I would.
The most prolific bug finder on my team is struggling with this question. The less the team decides to fix her bugs, the less interested she grows in reporting them. Can you relate?
There is little satisfaction reporting bugs that nobody wants to hear about or fix. In fact, it can be quite frustrating. Nevertheless, when our stakeholders choose not to fix certain classes of bugs, they are sending us a message about what is important to them right now. And as my friend and mentor, Michael Bolton likes to say:
If they decide not to fix my bug, it means one of two things:
- Either I’m not explaining the bug well enough for them to understand its impact,
- or it’s not important enough for them to fix.
So as long as you’re practicing good bug advocacy, it must be the second bullet above. And IMO, the customer is always right.
Nevertheless, we are testers. It is our job to report bugs despite adversity. If we report 10 for every 1 that gets fixed, so be it. We should not take this personally. However, we may want to:
- Adjust our testing as we learn more about what our stakeholders really care about.
- Determine a non-traditional method of informing our team/stakeholders our bugs.
- Individual bug reports are expense because they slowly suck everyone’s time as they flow through or sit in the bug repository. We wouldn’t want to knowingly start filling our bug report repository with bugs that won’t be fixed.
- One approach would be a verbal debrief with the team/stakeholders after testing sessions. Your testing notes should have enough information to explain the bugs.
- Another approach could be a “supper bug report”; one bug report that lists several bugs. Any deemed important can get fixed or spun off into separate bug reports if you like.