Many project managers and other non-tester roles search for proper categorization according to severity (A-B-C) of the defects and they search for description how to distinguish between each category. What are best practices? What is the Ideal description of categories?
There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including:
Having said that, one of the most important considerations you have to make involve: - Should we have two main categories or one per bug? - The "two main categories for each bug" approach often has, e.g., specific comments about 'what percentage of users will see this?' and 'how large is the impact?' - A "one main category for each bug" could be a blend of those two items (e.g., Sev 1, Sev 2, Sev 3) as described in Ivor McCormack's approach shown below.
Personally, I would consider Ivor McCormack's approach as a possible starting point, discuss options with your stakeholders, and adjust as necessary for your context.
Let's step back a moment and try to look at this from a different perspective.
If your team is using a defect tracking database to track bug backlog, then we should agree that the primary purpose of the defect tracking database is to
You started by stating "many project managers..." and this is the perspective that you should be approaching the problem from because it is usually the project managers (and hopefully dev and test managers/leads) who are triaging the backlog on a daily (or frequent) basis.
So, the categories you choose should be those that most help the project manager and other managers query on the types of bugs that are most important to them.
Severity is a subjective rating that reflects the negative impact on a customer. Priority (usually assigned by the triage team) is used to indicate how quickly or the order in which the bug/work item should be addressed. But, there are many other ways to slice and dice bugs/work items.
For example, we track test code defects, product code defects, documentation issues, etc in our databases. So, to differentiate between bug types categorize by "issue type."
Other categories we often use for triage include Blocking branch, feature path, milestone or sprint, triage, and status (active, in-work, resolved, closed).
I agree the number of categories should be kept to a minimum. Filling out a lot of unnecessary/unused fields in a dB is often pointless noise and clutters the important information.
IMHO, work with your project manager and understand what types of queries they want to run on the defect tracking database and use that to identify the categories important for your team.
Choose the smallest number of categories that you can get away with. If you don't know how many you can get away with, start with two. If you can't decide on two categories, you may not need any. And if you need more, your stakeholders will let you know.
If this area is not clear then, in my opinion, you should speak to him and figure out what they want. It is similar to risk based approach where the tester's (test manager) responsibility to find the consensus which item represents higher risk and which not.
On the other hand, from communication viewpoint the defects, the whole, are "playing" multiple role and sometimes the list of defects, and the defects itself should be able to provide non-technical information.
If you are in the position to create how to organize your defects you should consider a lot of things. On the other hand, Justing is right. There is no "right" answer. Every situation is different in a way and the devil is in the details.
According to ISTQB certification the categorization according severity and priority is defined as follows:
Severity (measures the impact of the bug to the software):
Priority (defines the desired order of fixing the bugs):