User reports a bug, send it to QA first or Programmer first?

Question

We have a live SaaS product and users report bugs sometimes. We have a functional tester and a programmer. When a user reports a bug should it go directly to the programmer or should it go to qa first and must be reproduced by qa before going to the programmer?

Answer 1

It depends

Each company has its own process for handling customer-reported defects. The one I'm most familiar with is more or less as follows:

• Customer support person attempts to reproduce defect and updates the report with any extra information
• Customer support or product owner searches defect management tool to determine whether or not the defect has been reported previously. In a large/complex application, it's not uncommon for multiple reports of the same problem to be made
• If at this stage the defect is determined to be a true defect, the report is turned over to the product development team. It may go to testing for more detailed reproduction, it may go to development for correction, or it may go to a general backlog for grooming and estimation.
• An emergency will often go through immediate reproduction, estimation, and be scheduled for fix as soon as possible in order to minimize customer problems. Less critical defects go through the normal estimation and scheduling process.
• If the defect is an emergency fix, it may be released in a patch deployment, depending on the current release schedule and whether the fix needs to go out immediately.

Some other factors that affect how customer-reported defects are handled:

• If the software is not a multi-tenanted SaaS offering, a special patch version may be offered to the customer(s) affected.
• If the software is multi-tenant, and has the ability to handle a/b feature enablement (i.e. a change for the software can be rolled out to a small subset of users while the rest continue to use the prior version), the fix may be made available to only that customer to allow for more detailed checking that the fix does not cause problems for other customers.
• If the customer has a history of reporting requests for changes to current features as bugs, the changes may be made as a bug fix but not prioritized for immediate release (customers like this happen. Sometimes far too often).

This is a long way from a complete list, but it should give you some idea of the decisions that go into what happens when a customer reports a defect.

Answer 2

It depends on your policy if you have one. It could go either way.

It could also be that it goes to the PO and they should approve it before continuing with the fix or putting it in the backlog.

Answer 3

It depends on the company to company and it's organizational work culture.

In my current and previous companies, When a end user reports a bug first it goes/assigned it the QA team. Then the QA team tries to replicate it in lower/Test environments (sandboxes).

If it's a valid issue then QA team documents the exact steps to reproduce it and after that it get's assigned it to the Developer/programmer for resolution/fixes.

If it's invalid then the same will get communicated to the user. This process will reduces the programmer's time.

Answer 4

First of all users should report using a reporting system, they should not be aware where does it go.

From there it depends on the size of your company, the product and how mature it is, the SLA you promise, the resource the company have and the kind of issues you expect.

Some examples I've seen over the years-

• A big financial company, all user issues are passed through a first level line of responders capable of solving simple issues since they assume most issues are actually user errors, configuration errors or people not reading the manual. Product managers are alerted on the more serious issues and they do a first triage as to where to forward it.

• A small startup delivering a new innovative service, they have only one tester that don't have the bandwidth to look at user issues so developers check the external issue board every morning, if a problem seems to require reproduction the tester will help with that.

• A medium sized company delivering safety critical software, issues must be solved quickly so the entire development organization are doing an on-call duties checking each issue as it arrives. If a problem arrives during work hours the person on call will try to triage it and request a tester's assistant if it is too complicated to reproduce.

• A huge company delivering free and very popular service, issues are reported through a community forum, many of them are answered by community members. Product managers or people in special roles monitor the forums and locate problems that requires the developers attention. A mail is sent to the entire relevant team and the team is responsible to choose who will triage it.

Answer 5

Generally, there are 3 "stages" in handling a bug report, even if they are all carried out by a single person. These are:

1. attempt to reproduce the bug, determine if it can be reproduced as is or if more information is needed, what steps need to be taken, is it just user error etc.
2. decide if this is behavior that needs correcting and if so how urgent / important it is
3. if a real problem was identified and when the priority demands, fix the problem and confirm that the behavior identified in step 1 no longer produces the error, and check if other non-standard behavior has been introduced.

In a lot of small companies with few developers there is a tendency to jump straight to stage 2 - the developer assumes they know what the bug is (often assuming user error is most likely) and decide if it is worth following up before even trying to reproduce it. They will only then go back to stage 1 when (and if) they go to fix it. If a bug report goes to the tester first, they are more likely to carry out stage 1 so that is one argument for sending all reports to the tester first. However the tester may then be spending a lot of time trying to reproduce a bug that the developer can instantly say "that's a limit on the XY system" or "yes, I know that, it's a side effect of something already on the fix list"

So I would suggest both developer and tester seeing the initial bug reports and hopefully communicating about them, but then tester has the initial responsibility of reproducing / confirming the bug before it is evaluated for Stage 2.

Answer 6

To add to the "it depends" answers, I'd say the primary metric for determining an appropriate process for your company/team is what's going to get the issue resolved the quickest for the stakeholders (both the end customer as well as the company)?

For me, that would mean determining what's going to get the issue triaged accurately and appropriately (i.e. is this a rare edge case that only affects a single customer, something that affects everyone but has a clear workaround, is it something that needs a hot fix ASAP, etc). Downstream from the triage, i.e. getting the bug fix prioritized, worked on, etc are other steps to also define, but figuring out the best way to triage the bug is the first step.

Answer 7

In general the programmer is a more skilled and more expensive workforce than a tester. Therefore, in my opinion, for an optimal division of work, the tester should receive all the bug reports. The tester should then handle those bugs he/she can solve him/herself and only pass the hard ones over to the big guns/the programmer. This way the programmer can spend more time what he/she is supposed to do, programming.

Answer 8

In an ideal world? Your support escalation process involves checking for reproducibility; user error is common enough that you don't want to be spending either QA or dev or PO/BA assets on filtering the simple stuff out.

However, you also never want to tell a client "we can't reproduce it, we're ignoring this". People are distinctly not fond of being gaslit, and that is how it will come across. Once obvious user error has been ruled out and support has escalated it to their highest tier, the next step is generally one of four things… and which of the four happens should, ideally, be somewhat context-sensitive:

1. If there is reason to suspect that it should be reproducible but they can't figure out how, flag a QA resource to help with a brief consultation. This path is about leveraging QA's extensive experience with how to exercise corner cases of the system, and is especially useful if the client was trying to "do something weird" that is particularly likely to have exercised less-used parts of the system.
2. If there is reason to believe that it may not be a supported use case for the system, flag a PO/BA to check whether it is an actual bug, or just a lack-of-feature. With well-designed software this should actually be fairly rare, because the system should clearly inform the user that what they're trying to do isn't supported (yet), but there's always something that slips through.
3. If it seems "just plain old weird" or if there is something unexpected such as a stack trace (i.e. "something that really should never be sent to a client in the first place"), flag a dev to come do an over-the-shoulder check. Many companies choose to have an on-call developer as the technical / internal escalation point out of support (as opposed to the managerial / "the client is screaming bloody murder and lawsuits" escalation out of it).
4. If all else fails, especially if it hit either path 1 or path 3 and they need to escalate further, call in your guru / "troubleshooter". This is the person in your organization who has a near-mystical ability to look at even the most complex problems and at least have some idea what could be going wrong and how to start trying to diagnose it. If you don't have one and your organization is of any significant size, you should budget to fix that. You won't need them often, but when you do they will absolutely save your bacon. Note that while this may happen to be "a senior dev", usually they are closer to DevOps, because resolving problems that reach this level often requires a diversified background.

Since you mention that it it a SaaS product, I will say that you really, really need a proper set of analytics tools. And probably to spend the dev resources to get them wired up "fully", although even just getting the basics in place will help more than most folks realize. Without these, trying to diagnose any complex problem in a SaaS environment is at best far more painful than it needs to be, and at worst simply implausible (or even truly impossible) to do.

Answer 9

When a user reports an issue it should be reviewed and ideally recreated by the QA/Tester prior to the developer being exposed to it. Unless the user is a code-level expert in the software they will be reporting only from their sphere of knowledge. Any developer encountering the defect directly would need to recreate the issue prior to fixing it. Having what could effectively be called a QA-Layer between user and code would ensure the defect is correctly reported, enabling it to be fixed and released in a timely manner.

Answer 10

This sounds like you are missing a production support/issue tracking process, as production issues should never go straight to dev or test.

Even if there's not a person playing the formal support role, a good issue tracking process and system could help capture issues in a way that they could be reproduced. A well written issue report should read just like a good test case. If there's a lack of staff, a tester should be able to review an issue and get enough details to reproduce it, so using QA to screen the issues for the developer might be a good idea.

Answer 11

In My Current Project, As Issue needs to be quickly handled it is assigned to Both Developer and QA. QA tries to replicate the issue while Developer tries to do thorough code check to ascertain it will work properly in the given scenario. Sometimes QA gets to the issue first while sometimes it is Developer that gets to the issue first.The process is different in different organisations and it also depends on the workload which is currently there on QA/Developer. At the end it is Team Effort to deliver Quality and nice user experience.

Answer 12

I think any bug reported by a user should first be shared with the QA team. This would give QA team a chance to work on the areas that were missed while producing test cases. Moreover, the QA team would be able to better analyze the situation to locate any flaws in the design and share them with the programmers.