Should software testers fix the bugs they find?

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?

An example is a trailing comma in a JavaScript array, it’ll go berserk in IE7, and it’s easy enough to fix (remove the trailing comma) so I’ll just fix it if I find it. Another is an button in IE7 that is meant to submit a form but won’t. To support IE7 you need an input type=submit to work. Again, I’ll change it so that it works.

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.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

3 thoughts on “Should software testers fix the bugs they find?”

  1. Great topic. I have this discussion all the time with testers and my answer is an emphatic “NO, testers should NOT fix bugs.” First, you are making the assumption that testers have access to the source code. Most do not as it is usually “guarded” by developers.

    Even if testers do have access, there are development standards that testes rarely know about. Testers are simply not in these discussions; nor should they be. Making a simple change might result in a considerable amount of re-work by the dev team as they will have to go back and make the change adhere to these standands.

    There could also be automated Unit Tests developers have in place that might get broken. But testers won’t know this one way or another because they typically they don’t have access to execute these tests.

    Another underlying reason why I tell testers “NO” is to reemphasize the roles on teams. Developers need to focus on developing, testers need to focus on testing. Each brings a unique discipline to the table. By blurring the lines you potentially lose some of that disciple.


      1. Actually I am. Let me qualify my answer: I am a Testing Manager Consultant who is typically brought into pretty bad testing situations. Most shops I deal with have mostly traditional manual testers who have been doing it that way for years and have ZERO development training. To the extreme that in some situations they have never heard of an if-then statement. No kidding.

        Most testers I work with are great at helping write Epics/User Stories/Acceptance Criteria, and do a fantastic job working with the rest of the team to come up with test cases and the write some wonderful scripts. The break-down happens when they are then tasked with automating those scripts. Asking someone with zero knowledge of object oriented programming to create and maintain a scaleable, maintainable automated framework is a disaster waiting to happen. They can do it using cucumber. But it will quickly get out of control without A LOT of coaching from a development trained “coach”.

        So as a rule of thumb I always tell my testers to focus on testing. Let the developers do the development. Even if it is something as simple as a misspelled word on a web page. Let them do. Stay focused on the testing effort.


Comments are closed.