Is a coder that 'quality checks' bug fixes and bugs raised by testers a recognised role?

Question

I've recently found myself frequently in the position where I'm checking both bug fixes by other programmers, and bugs raised by the QA team.

Any bug fixes frequently end up having 'collateral damage', and I've found it invaluable to go through any recent fixes, and analyze what other parts of the system could potentially have been impacted by the changes. It's been instrumental in maintaining the reliability of the system. Without this process, the testers generally find new bugs raised, and rarely recognize the cause as the recent bug fix.

I'm also quite often going through new bugs raised by the testers, analyzing possible causes to determine if there's a root cause that may impact on other parts of the system, quite frequently merging two or more bugs into one case. It's essentially doing the 'investigation' part of the bug fixing process, so that another programmer can focus on just the coding.

The question is, is this a recognised role? It doesn't seem to fit into the 'Programmer' or 'QA' job title neatly, it's kind of in-between. Or is the need for this role more a consequence of bad process or bad design?

Answer 1

In just about every place that I've ever worked, these responsibilities fall to the engineer who is responsible for fixing the defect and the quality engineer responsible for ensuring that the defect has indeed been fixed and the system is still functioning as intended.

When a problem is reported (by anyone - another engineer, someone in quality, or after a deployment), it gets assigned to an engineer for investigation and resolution. This person is responsible for not just developing the solution, but for tracing from requirements through implementation and any associated automated tests to make the appropriate determination. This engineer would make sure that the defect actually is a defect and not user error, then make the appropriate updates to some work product to address the issue. After the fix, if there was an implementation change, I would expect the engineer making the change to run through at least a basic set of tests to make sure their fix didn't introduce other problems into the system.

After an engineer has finished fixing the system, I would expect someone from quality assurance to verify that the defect has indeed been resolved and close out the defect. I would also expect that they would run other tests on the system to ensure that no other defects were injected. These would probably be more thorough or rigorous than the tests run by an engineer. If any defects were found, they would be added to the tracking system and the process would start again.

It seems to me that injecting a third person in what should be a two-person process (well, technically a three-person process, since there's probably someone that takes in the reports of issues, prioritizes them, and perhaps assigns them) just adds overhead. The investigation process of fixing a defect is crucial to actually providing a good fix for any problems, as well as maintaining (or improving) an understanding of the system. Except on the most trivial systems, I don't see how a person can just be expected to write code without a good understanding of what other modules or subsystems their code is interacting with. It's also part of professional responsibility to ensure the quality of one's work to some extent.

Answer 2

These are two roles. Both roles belong to the software change control management.

The role that pre-screens change requests is called triage. This role classifies each request as defects or enhancements, correlates with similar requests, assigns priority (or rejecting low-priority requests)

The role that reviews maintenance code changes is code review.

Answer 3

This person is a Reviewer, and probably a leader in their environment. On the "fixing" end, you're talking about code-review-on-steroids. Your best programmers should be doing this task, and their advice should be treated as the golden rule by their peers. On the "testing" end, you're talking about defect triage and trend analysis. Only someone who has deep knowledge of your system can do this well, and their opinions should be respected by both testers and coders.

Of course, in the real world, this is scut work doled out to the lower echelons if done at all. More's the pity.

Answer 4

There are two titles that work for this position depending on the circumstances:

Mentor Programmer:

With a new employee that is learning the ropes of your system this can be a very valuable position. It gives you the chance to instruct on the specific code, the system as a whole, the bug reporting software, and any of the written (and unwritten) rules for working with the QA team. As with any new employee you want to be very hands-on in the beginning and then back off once they've heard something once or twice and give them the chance to do it themselves.

Nosey Programmer:

I think we're all guilty of this at one point or another, perhaps it's slow and you need a little something extra or maybe you're working on something big and just want to do something small for a quick win, but ultimately you're sticking your nose into someone else's business. You may be saving them time in the short term, but you're harming their overall productivity by robbing them of the chance to learn from their mistakes. It also is going to look like you don't trust QA or the programmer to do the job correctly.

I've worked as a Support Programmer, a possible third title, but that was strictly doing bug fixes after deployment along with third party interfaces, add-on products, and anything that didn't fit neatly into a the major release development schedule. I got really good at learning from other people's mistakes, and learning what mistakes certain programmers were likely to make over and over again. They made those mistakes because they never got the chance to learn from their own mistakes and because they knew they could rush something out the door and it would be someone else's problem if it didn't work quite right after deployment.

Answer 5

I used work in a role called a Defect Coordinator. I was responsible for initial triage of the defects (where possible) so ones that were clearly Not Our Problem/Not A Defect didn't end up on our weekly reports to management, dishing out defects to the team (and chasing them to see what the progress was), and verifying that the fixes actually got released. I should point out that the triage was not necessarily done by the person who ends up fixing the defect; it depended on the complexity of the defect really. I know this role as an Error Manager in other organisations.

As for reviewing fixes, this fell to the team. The fixer would choose two or three relevent people in the team who could give proper feedback on the change. We used Code Collaborator to review and a link to the review would be included in the defect's report to show it had been done. The fix would not be approved for submission until the reviewers were all happy with the fix. Root Cause Analysis was also part of the process but I found that upper management did absolutely nothing with this information.