This post is part of the Pride & Paradev series.
Should software testers fix the bugs they find?
Software testers should fix the bugs they find
I admit it, I often fix bugs I find. I can’t help it.
After being on a project for a couple of months you start to notice the same trivial bugs being found again and again. If you know how to fix it, why not fix it?
The benefits are that user stories will move to ‘done’ faster as it doesn’t require programmer involvement, and it’s less disruptive to the programmer who will be working on another story and will need to context-switch.
Software testers should not fix the bugs they find
You’ll often be tempted to do a quick bug fix when you know why something is broken, but you should avoid it. If you quickly fix it, the programmer who created the bug doesn’t get the feedback that they made a mistake, and will repeat the same mistake over again.
Over time, if the programmers know that you’ll fix bugs, they’ll naturally start providing you with buggier code as they know that you’ll just fix it as needed.
Programmers crave feedback, both positive and negative, that’s why it’s good having a tester on an agile team. But fixing bugs yourself means there’s less feedback being given, and less communication happening.
There’s a small chance that you may introduce some regression bugs when fixing a bug by yourself, but this isn’t the reason alone to stop doing it, there’s better ones I have already mentioned.
Another minor reason is that it may look like you’re not finding bugs, but this again shouldn’t be reason alone because testers shouldn’t be measured on how many bugs they find.