So a few weeks ago, I gave the green light for my team of testers to start fixing bugs.
“Sweet mercy, what have you done?!” I hear you cry. “If testers start fixing bugs, they won’t want to find them anymore and the developers will get careless and there will be more bugs but they won’t be found and then society will collapse and the world will explode!”
Yes, I too had some misgivings about this idea. But for our situation, it seemed like a logically good use of our time. Our test team often find ourselves with a significant amount of downtime, which we usually use to improve our automation suite and to build on our technical skills. But lately we had been experiencing a longer than usual amount of downtime and we were fast running out of valuable things to do. We all have .NET coding skills, so with a large backlog of bugs to fix it seemed like a logical move.
But yes, I had some misgivings. So I laid down some ground rules.
1. This will be a “pull” system. That is, testers can decide to fix bugs if they feel it is a good use of their time. Other team members cannot tell testers to fix bugs.
2. Testers will only fix low-priority bugs. So a tester’s bug fix will never be on the critical path for a release – it will always be optional.
3. Testing tasks will always take priority over bug fixing for testers.
So far it’s been perfectly fine. I have to admit that I didn’t actually fix any bugs and that most of the bug fixing was done by my colleague Pete, who was on a bug-fixing spree. So, the results? More bugs were fixed, team morale was higher and the world didn’t end after all.
Now that more testing work has come in, the tester bug-fixing activities are on hold. But I expect this we will pick this up again the next time we get some time to kill.