Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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:
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.
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.
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.
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.
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.
