I've heard two guys from Microsoft and Google saying testers in those companies fix defects. Personally I think it is Ok and a better contribution than just creating a new bug ticket (at least in some cases).

I really don't know if this is the forum where I have to ask this kind of opinions but I would like to know what you have to say about it.

  • 4
    If this information about those guys somewhere online?
    – dzieciou
    Commented Nov 14, 2012 at 5:49
  • yes, it is but I don´t remember where. Anyway, I remember a conference where mr. wittacker (from MS first and google now) talks about testing and tells their listeners about that. It has to be in youtube with the name "Test is dead"
    – lontivero
    Commented Nov 15, 2012 at 3:36

7 Answers 7


If they have the knowledge to fix in, why not ?

I can see where the bug should still be reported for those places that want traceability etc and presumably the tester will first write a failing test to demonstrate the bug...


As a tester on a small team in a large organization, my answer may be skewed from that of a tester in another situation.

I'm all fine for testers fixing bugs, but, we also need to realize that we specialize in testing, and developers specialize in coding. We could fix it, and it could break something else that we don't know about. At the end of the day however, in many organizations, the code is owned by the developers.

Actual answer, yes, I think it's fine, so long as the team is alright with this and the code is reviewed and checked in by a developer with a stake in the code.

  • 10
    If the tester fixes a given bug, who verifies that fix? Commented Nov 14, 2012 at 12:09
  • In theory, there would be more than one tester on these teams. I'll maybe see about editing my answer later today, but, there does need to be some sort of process in place for these circumstances. Commented Nov 14, 2012 at 12:33
  • Or given that in some teams now there is not such a rigid tester/dev division then a dev checking over the fix with the tester would be fine. 'Hey, I noticed the code had < instead of <=" job done, fixed and shipped Commented Nov 15, 2012 at 4:20
  • @JoeStrazzere I guess dev verifies it and then some other test engineer reverifies it and then if there is another bug (missed by dev verification) then tester who fixed it earlier fixes it again then again dev verifies it and cycle continues :)
    – Tarun
    Commented Nov 15, 2012 at 5:40

No, they shouldn't.

The major reason is that the natural role of Developer is to stand up for idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not working".
If the same physical person acts for two opposite roles, this may lead to compromises with themselves.
Specifically speaking, sooner or later you will be tempted:

  • either to make worse code, just to satisfy minimum requirements,
  • or to perform worse testing, to avoid detecting bugs in your own code

Yes, if someone have experience "changing your hats", they can combine the roles. Anyways, at any given moment they should clearly understand what role they are playing at very this moment, a QA or a Developer.

If you are QA and you are willing to code (or vice versa), the best suggestion is wearing different hats for different projects. This way, you are QA in a Project_1 and a Developer on a Project_2.

  • 3
    I'm inspecting a house and fund a loose plank, cam I get a hammer and nail and fix it ? Commented Nov 14, 2012 at 13:38
  • 1
    @PhilKirkham No, because it may appear that all planks are loose, and you have found just a single one. Attempting to fix it by yourself is likewise attaching it with a sticky tape, instead of finding that, e.g., all nails are 0.75 inch long instead of 1.25 inch. I've seen some houses like that. And some softwares! :) Commented Nov 14, 2012 at 13:53
  • 1
    @PhilKirkham Continuing a housing metaphor, it's everyone's own decision whether to wait 6 months or to die when a ceiling falls due to the very same nails problem. I prefer to wait. :-) Returning back to SQA, the specs are the ultimate judge. If it says the "nails" must be 1.25 inch, and they are not, the testing should fail, the issue raised to the developers, and so on. However, QA engineers often compromise with themselves by accepting/sticky-tape-fixing something that is indeed broken. And we see the results here and there. See Andrew's comment above. Commented Nov 14, 2012 at 14:44
  • 2
    @bytebuster, based on your house analogy then logically we should not rely on the validity of unit tests since developers write the code and they also write the unit tests. So, it would then follow that it is wasteful to invest in writing unit tests. But, we know that is fallacious. Also, your assertion that testers compromise by "accepting/sticky-tape-fixing" is ridiculous. As is your assertion that specs are the ultimate judge and the role of the tester is to prove things are working. These are archaic and antiquated prejudices. Perhaps this has been your experience, but certainly not mine. Commented Nov 14, 2012 at 16:13
  • 2
    @Phil - if (as an independent surveyor) you are inspecting a house and find a lose nail, no you CAN'T fix it yourself. The same should apply to independent testers.
    – Andrew
    Commented Nov 15, 2012 at 20:40

There seem to be a wide range of answers from "Yes, this makes sense." to "No, don't you dare." I can see both sides of the question so here's an answer in the middle. It depends.

It depends on the role of QA on a particular project.

  1. If QA has been involved in the software development lifecycle, if QA has played a role in defining requirements from the start of a project, and if QA feels like they have the support of project management to take a proactive role, I'd say go for it. I've always welcomed testers and QA people with an engineering focus to take some time to understand the code that underlies the systems they are testing, and there's no better way to learn a system than to fix bugs in a project.

  2. On the other hand, if QA isn't involved in the overall project, if QA doesn't have a seat at the table during the requirements phase and during the implementation of a project, then you are going to want to consider that QA may not have enough information to fix bugs without introducing more complexity (or even without understanding how the bug affects the overall development effort). Having QA fix bugs without the involvement of a developer or someone in project management could cause a range of problems. Maybe development has decided to delay the implementation of a feature because the business hasn't fully elaborated on a requirement? Maybe a particular bug is present because a developer is waiting for clarification?

In summary, I welcome a more involve QA effort on all the projects I develop, but I'd only be comfortable with QA fixing code if I were confident that they were involved in all aspects of the project.

  • Much like everything in testing, it depends on the context. Commented Dec 2, 2012 at 2:09
  • Good answer, though IMO, in situation 2 I'd be pretty worried about QA's ability to test effectively too.
    – testerab
    Commented Mar 9, 2013 at 21:56

It actually depends on how much does the tester know about what's under the hood?

If the tester is involved in the development and has knowledge of how to fix the issues, then why not? It would in fact save a lot of time with all the back and forth over email or whatever system there is in place to raise issues to developers and re-testing and all. This way the developers too get more time to focus on new developments and enhancements. Plus, testers have a good hands on knowledge of what's under the hood so they have also better understanding of designing tests.

Regardless of whether a tester fixes the issue themselves they need to convey information of all the changes they made to the developers and product owners so they are aware and also can help ensure the fix doesn't break something else.

On the other hand, if the testers are doing UI, UX and interface testing, they may not necessarily know what the back-end looks like, then they simply cannot fix it.

Even if testers have the knowledge of coding and can debug the issue, all they should do is find the root cause and provide all the information to the developers. The developers and then do impact analysis of a possible fix throughout the entire system which the tester may not necessarily be able to for any reason (may be lack on knowledge of the whole code base or access to it or whatever else).


Yes, they can if that is what the situation demands.

If you're following Agile methodology, then of-course tester can fix bugs if they want to. In Agile, the boundaries of developers and quality engineers blur. Depending on the capacity and backlog, team-members take up user-stories. And if there is a bug to fix which the quality engineer(QE) is willing to fix the bug and verify it later - then surely he can. He can step in the shoes of a developer if the need arises(assuming he is technically proficient enough).

Perhaps, in waterfall environment such flexibility won't exist where developers and QE roles will overlap.

I am in favor of QEs going ahead and fixing bugs. More so,when practicing White-Box Testing they are well versed with the code flow. Figuring out a missing condition in the code and then fixing the bug will surely be a testament to the technical proficiency of the QE.


If you ask if they should do it, I'd say they don't need to. On the other hand there's something to be learnt from fixing bugs, so why not?

The answer "it depends" is probably the best here (surprise, surprise :D) because not every company, team, project, and product, etc. is the same, so two testers will need to choose a different approach depending on their context.

Personally what I find hard is that as a developer, which I'm when fixing some bugs, I try hard to write code, even test code for my changes, that can work. But I don't pay as much attention as I'd ideally want to focusing on risk (what can go wrong). This might be only me, I'm just trying to say that this is something to pay attention to when being in such a double role. I think this can be further mitigated by pairing with colleagues - pair programming and pair testing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.