As a lead tester, you fall somewhere on a scale between being completely passive about bug fixes and being in complete control of them. If you are completely passive, you are managing neither the product nor its quality. If you are in complete control, you are managing both. Neither of these situations is good for you; what you should be doing is managing the quality.

In an ideal world, there is a balance between the QA, R&D and product managers, and bug fixes are determined by agreement among the three. In the real world, however, there is often imbalance: one of the three will make all of the decisions. That’s where the scale comes in: are you making all (or most) of the decisions, or is your voice never heard?

I don’t believe that you can claim to manage quality if you’ve never argued about a bug. It implies either that you believe that you are the only one capable of making a mistake (the whole point of your job is that others make mistakes, too) or that you don’t care if other people’s mistakes make it to production (again: the whole point of your job is to prevent this). Either way, the product’s quality is determined entirely by other people’s responses to your bugs, making you not a quality manager but a bug-sniffer.

Obviously you get things wrong sometimes, we all do, and obviously some bugs matter more than others, and some element that you’re not aware of may make a bug matter less than you originally thought. But if you’ve never said “I hear you, but I still disagree” then I think you’ve given up, and I’m sure your product’s quality has suffered as a result.

The flip side of this is when everything you put into the bug tracker gets done, no questions asked. In this case, either you are always completely right, or you’re finding many things that actually deserve to be argued about, but nobody is arguing.

I’ll give you an example. I once worked on a project where several of the testers flagged a UI change as a bug. It was, we argued, a security risk, because when the change was designed a password verification step was removed. The developer agreed with us and added the password verification step, only to remove it three days later; the product manager, back from holiday, explained the the step was removed by request of the customers, who did not consider the function at all dangerous.

If the product manager had not reviewed all of the changes, or did not care to argue about them, the quality of the product would have suffered: a change requested by customers would have been rejected because we were used to the password verification step and assumed it was correct.

When you manage the product without being the product manager, you make these decisions based on the information you have as a tester. If that information is not correct, the product’s quality is compromised. And quality, not product management, is your job. You should listen to those who have all of the information, and argue for your bugs on a case-by-case basis.

The right place for you, therefore, is in the middle of the scale. Don’t fight over every bug, but don’t ignore seemingly wrong bug rejections or version assignments, either. Make your case.

One final note: if the reason you’re managing the product is that no one else cares, or no one else knows enough, it might be time to get a new job, either as the product manager in your current company or as a tester in a different company.