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.
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.
