BTL_Software Testing Training

Blog

 

Who fixes the bugs?

Mar 26

Written by: Danny R. Faught
Thursday, March 26, 2009 11:16 AM 

Eric Jacobson discussed an interesting question from Roshni Prince in "Dealing With Smarty Pants Tester." The issue is how to deal with a tester who wants make code changes to fix bugs after finding them. Eric says that this is a bad idea if the bug fixing efforts prevent the tester from doing a thorough job of testing.

I don't know what context the question came from, but it's interesting to explore some general answers. I agree with Eric that it's not good for a tester to fix bugs if it causes the tester to get behind schedule. But it's worth exploring a bit deeper than that.

As with any question about roles, I like to look at it from a broad perspective of everything that the organization needs to get done. On a well-run agile team, it would be natural to consider whether a tester, or anyone else on the team, should spend time fixing bugs. Just because bug fixing is not a traditional activity for a tester doesn't mean that testers should be discouraged from doing it, and you don't have to follow an agile process to make it work.

I worked on a team once where some of the testers were asked to help with bug fixing when the development efforts got behind schedule. In that organization, because we were testing an API, all of the testers had programming skills already. There was such an emphasis on programming that many testers expected to move into a full-time development role as their career progressed. One big downside of this was that it was difficult to retain the top talent on the test team.

If you have development and test teams that were staffed based on the assumption that developers would develop and testers would test, having testers do development work can throw off the balance of your staffing plans. Also, there is overhead involved with the testers taking time to get familiar with the development environment and the established development processes. In some organizations, there may be cultural barriers to having someone whose job description isn't "programmer" touching the product code - that hurdle would have to be overcome.

One upside is that bug isolation skills have a lot of overlap with debugging skills. A sharp tester may be really good at identifying the source of a problem, all the way down to the line of code. It may be a short leap to design and implement a fix while they're down there.

When I teach bug isolation skills, I tell testers that in many cases, it's beneficial to use their skills to do more work to isolate bugs than they're currently doing, though not necessarily to the level of looking at code. If the question were to come up on a team I'm involved with, I would look at how easy it would be for the tester to come up speed on the development environment, how easy it would be to get the code changes from testers accepted, and how to balance all of the development and testing tasks that need to be done.

Trackback Print
Location: Blogs Software Alchemy
Tags:

6 comment(s) so far...

Re: Who fixes the bugs?

If they have the skill why not? Of course I would expect such a fix to go through the same level of peer review that the developers would and the regression test has been identified already. There have been countless times that I have seen a "non-critical" issue languish because the developers have higher priorities, perhaps letting testers resolve the straight-forward bugs would offer relief to a team that is suffering from a high backlog of issues.
Developers testing, testers developing... what is the world coming to?

By Rick Martin on   Friday, March 27, 2009 11:48 AM

Re: Who fixes the bugs?

Also, for all those testers who are insisting that the developers do better unit testing, it would be very interesting to see what kind of unit tests the testers come up with. Either the testers or the developers or both are bound to learn something important from it.

By Danny R. Faught on   Friday, March 27, 2009 12:44 PM

Re: Who fixes the bugs?

The world has not changed so much that it is "okay" for the same person to fix and develop code.

Independent is the still the best way to address this. Agile or no agile; you need two separate individuals
to code and test.

Haven't we already learned this lesson numerous times?

By Denise Canty on   Friday, March 27, 2009 1:04 PM

Re: Who fixes the bugs?

Hi, Denise. Though I understand the general idea of having a tester who is independent of the developer, I'm not quite sure I understand your point here. Maybe you mean that there should be someone to independently test the code change if the tester fixes a bug? I can see that that might be worthwhile.

I'm not sure what you mean by "the same person to fix and develop code."

By Danny R. Faught on   Friday, March 27, 2009 3:06 PM

Re: Who fixes the bugs?

I'm always a bit taken aback at the folks who thinks this is a black and white issue. It always depends on the team. As a tester, I do plenty of feature and bug fixing in my team's product. At the same time, I'm responsible for assuring that the overall test strategies are in place. Do I have to sacrifice testing for the development work? Sure, when is work not a set of compromises? The value I gain from better understanding my team's code outweighs it all. Knowing how things were implemented in various parts of the product enables me to more quickly identify potential problems, learn what my developer's weaknesses are, and develop testing strategies for any portions of the code that I see could be problematic. Of course it's best not to verify your own bug fixes, but that goes for anyone on the team. I also think it's great to understand what it's like to be on the development side of the test/dev relationship. There are various nuances of the job that I wouldn't have ever discovered if I hadn't been a developer first.

By SocraticCyborg on   Saturday, March 28, 2009 12:06 PM

Re: Who fixes the bugs?

boy what a question...

I've been doing this long enough to remember when developers tested their own code, and the users discovered the bugs. so, the birth of testers. they are two different hats, and cannot comfortably be worn at the same time, at least not in public. as a tester, I can code, because I was a programmer, and I know that hat, but as a tester, I don't want to touch the code. I can suggest corrections, and offer solutions, but I'm offended by the suggestion that the developer would want to do what I do, and if I wanted to do what they do, I would. The tools I build for myself are tailored to the code I'm testing, but it would be sad to waste my testing talent by having me fix the code! of course, it does depend on the situation, as mentioned above. In a small boat, all hands row, but if the shop has any size, it is a bad idea to mix up the roles. I've worked in a mixed shop, for a manager that was running both dev and QA, and the product (and therefore the users) suffered. we should be partners, not interchangable ... another problem is that some testers think it is a stepping stone to development. I think the reverse, that I evolved from a programmer to a tester.

By kristin on   Friday, April 24, 2009 6:38 PM

Your name:
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel