Imagine this: you’re testing the software. You find a pesky bug. You report it to the team. Someone comments, “It’s an edge case.”
The bug gets put low in the backlog and becomes forgotten. A month later, users start complaining about the same issue, and it is suddenly expedited. It gets fixed in a day. You sit there with your hands crossed. You’re proud it was fixed, yet also disappointed that when you told others about it - it was ignored. You keep reminding everyone: “I told you so!”
I’ve read several bitter posts from the testing community on this topic. I have been bitter myself. I used to say, “Testers do not win popularity contests.” With more and more experience, I have been humbled, though. Honestly, we all could do a much better job getting those bugs fixed.
Step 1: Drop the God complex
Sure, you’re an expert in testing. Of course, you feel the bug you found is essential. As is your colleague’s bug. They may feel completely the same.
I have found bugs in my career that I felt had to be fixed immediately. Once the product’s main functionality did not work, I rushed to report it. When someone asked me for data on the impact, I was frustrated: don’t you see how important this is? Don’t you believe me?
Yet when I looked at the actual data, I understood that I did stumble on the edge case. It affected 1% of the users. It was important, but not as important as some other issues we had competing with it.
As much as we think we know what is important, our gut feeling or role status is not enough to get the bug fixed.
Step 2: Respect the bug: Tell a story that speaks to many people
I likely do not need to remind you of the power of bug reporting: add clear steps, the environment, and screenshots. In case you forgot, I have a high-level explanation in my Quality Fundamentals article on work item types.
As much as you understand the system and assume that a dev will understand your bug, too - treat the bug with respect.
Not only add the steps but also think about what is important to which people. This way you could get many allies to get it fixed.
- Could you get data impact of this issue?
How many users are affected by it? Could there be a cost impact? Or it’s both the customer-facing and infrastructure cost-facing issue? Ask the data and/or support teams if they have any reports.
- How does this bug align with the company’s priorities?
Do you fully understand what value is for your product? How does this bug play into the landscape of other bugs? Which ones are more important to be fixed? Sometimes raising a bug that won’t be fixed may just generate more noise and won’t get it fixed.
- Which departments in the company may be interested in this bug?
User experience? Engineers? Support? DevOps? Establish a link with different departments and share the bug to see if it aligns with any work they’re doing and make them aware of it if it’s relevant for them. This is a win-win: if it aligns with the interest areas of your colleagues, they may even provide extra input and weight to it.
Step 3: Pitch your bug
If you did step 2 right, your bug report will be concise, clear, supported with data, and aligned with the priorities. If the story speaks to many people in the company, they will be your allies and can aid you in finding a way to get it prioritized.
Who does prioritization in your company? Talk to them. What is important to them? Present the finding and add the why. The actual why. Not why YOU think it’s important, but why WE think it’s important. Why it’s relevant to get it fixed for the business.
Summary
Do not just drop a bug without selling it and hope that it will become important. Treat every bug with the respect it deserves. Sometimes you’ll raise one to a level you never imagined, and it will be fixed the same day. Other times you’ll be humbled and realize it’s unimportant even if it looked critical to you. And other times, it may take time to gather more data and have more people face the problem to understand and prioritize it appropriately.
Sometimes you’ll be successful. Sometimes you won’t be.
If you treat bugs with respect and truly make sure you did all you could to sell them, you will definitely change the whole mindset about testing, build great connections in different departments, and help get so many more bugs fixed.
Andy Glover’s Illustration on Treating Bugs with Respect, source: Cartoon Tester