If your test team is judged by how many defects it raises, congratulations: you have invented a system that rewards people for finding as many defects as possible.
Do not then act surprised when you receive a flood of low-value tickets about spacing, wording and edge cases nobody cares about while the important risks get the same attention as everything else. We can review the team’s approach if you want an outside view, but start by looking at what behaviour you are rewarding.
Defect count is a terrible productivity measure
A tester who finds one issue that prevents duplicate payments may have created more value than somebody who logs forty cosmetic bugs. The count says the second tester was forty times more productive. The count is an idiot.
Defects matter because of consequence, not because they exist. Of course small issues still matter sometimes. A typo on a medical warning is not “just content”. Context is the whole point.
Check whether the team understands the product
High volumes of trivial defects can mean testers have been separated from users and business risk. They know how to compare the screen with a specification but not what the service is trying to achieve. The question is whether the number of bugs really justifies a delay, not whether the defect counter is impressive.
Ask them what would genuinely damage the customer or organisation. Ask where they would spend one day of testing if launch were tomorrow. Good testers usually have strong opinions. If the answer is simply “execute the remaining scripts”, you may have an execution factory rather than a test function.
Do not solve this by suppressing defects
The answer is not to tell testers to stop raising low-severity issues because management wants fewer red dots. Sometimes those issues are useful. The answer is to improve prioritisation and coverage so the team spends most of its energy where failure matters.
And if developers routinely reject anything they consider minor, make sure that has not trained testers into elaborate arguments over severity instead of quick conversations and sensible fixes.
Look at what never gets a ticket
A mountain of low-value defects can distract from the opposite problem: important weaknesses that never become defects because nobody explores them. Poor recovery, confusing journeys, fragile integrations and bad operational behaviour can sit outside the neat comparison between requirement and screen.
Ask the team what concerns it has that are not represented in the defect count. Strong testers often have useful worries before they have a reproducible ticket. If your process only values logged defects, you may be filtering out the thinking you actually pay testers for.
If you want us to look at what your testers are finding, what they are missing and whether their effort matches the product risk, speak to us. We will care a lot more about the defects that matter than the number in the monthly report.