How do you convince stakeholders to fix a low-priority bug that you know will cause big issues later?

Sometimes a bug looks harmless on paper maybe it is buried somewhere in an obscure part of the app, or occurs under very rare conditions but the tester instinct thinks it could cause some major shafts down the road.

How do you get the decision-makers to see the threat and prioritize it before it becomes a full-blown fire in production?

1 Like

How will you convince us that it will cause big problems :smiley: Dont worry about fixing everything. Fix that matters.

As I always emphasize, speak with Data.

There is a quote: “if its not yours to make decision then don’t worry about making one”. Best you can do is keep that bug in backlog, keep an eye as well. If some issue appears in the future, you can show your findings, always report anything that you find, may be its not important to fix right now but keep an eye always!

Never stress yourself on low p bugs. Keep them noted however. If you think it will cause hazard in Production, back up your case with data.

Edit: Another tip I’d add from experience: As we cant test everything, we cant fix everything either. :slight_smile:

6 Likes

Definitely not worth fixing every defect, even if they are very scarry. We often have no idea whether a component is about to be removed in near future anyway, and so unless the defect is seriously blocking a bunch of other test cases I often advocate to reject and give a good reason behind marking a bug as a wont-fix. “WONT-FIX” bug resolutions can actually save you, especially if you put into words why not. It’s a huge mental load to keep an eye out for a bug biting back when you eventually amass a lot of them. It’s useful to remember that we only discover a fraction of the defects anyway, and best to instead go hunting for another one. Always be open.

1 Like

The testers job is just to provide good and complete information. When you raise the bug, describing the real world impact the bug has is often helpful when it comes to the prioritisation. I.e. why does this bug matter? What will happen if you don’t fix it? (not always easy to know I know). If you do this then the team as a whole (or the PO/PM if you have one) can decide on the priorities. Just make sure you are giving all the information you can to help people make a decision. Frame the bug in terms of risk and outcomes and you’ve done what you need to.