should there be separate work item types to track bugs for QA Vs. Production

Question

What is the best practice - should there be separate work item types to track bugs for QA Vs. Production?

We have a discussion going back and forth with the QA team. QA team is recommending to have a separate work item type for QA bugs (called issue) and  use the "bug" type for production issues.

Charlie Misonne · Answer

Hi @Vimukta Talwar

That's actually an interesting question!

I work for many organizations and I've seen multiple ways to handle this difference.

Should there be a separate work item? No, not always. Can there be? Yes certainly.

A common approach is to use Incidents for anything that is being discovered in production (by users). Someone from the development team will investigate the incident and raise a bug if it is indeed a coding error.
You'll end up with an incident linked to a bug because developers typically do not work on incidents directly. They often come in via a separate channel like a JSM portal.
Note: incidents are not always caused by bugs.

I also read about using Failures for production bugs but I've never seen it on a project I collaborated on.

You could also decide to rely on the fix and affected version fields in Jira. When you filter for all bugs that were reported for a released affected version you know it's a production bug.

There is also a distinction between defects and bugs. I don't think it relates entirely to your question.
You'll find many articles and discussions on this topic. ISTQB defines the exact definitions.

That being said: there can certainly be reasons to make the distinction. Reporting is one of them.

Can you tell us why the QA team needs this?