What is the most common labels for the bug severity: High-Med-Low-etc., A-B-C-etc., 1-2-3-etc. or different? Where they origin? What is the best practice to use?
A label is just a label.
It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity* your stakeholders may take appropriate action. E.g. stop releasing the product or postpone fixing the bug.
For instance, we define Sev 1 when whole system is not working because of the bug, and Sev 2 when only one of the important features is broken. We usually do not accept Sev 1 and Sev 2 in the release, while Sev 3 requires further discussion.
*Obviously, this is simplification. Severity alone might not be enough to take an informative decision, so other parts of bug report can help decide.
The ratings that I see in common use and have used historically are:
The main decision that needs to occur for each bug is "Are we going to hold the release of the software because of this bug?". If so then it is a Sev 1 or 2, if not then it is a severity 3 or 4.
On really big projects with hundreds or thousands of bugs, you need to add priority as well to allow business stakeholders to choose the fix order. That normally gets a 1-4 rating as well of :
With this system in place, the severity is a technical impact that is set by the testers and cannot be changed. The priority can change throughout the life of the project, especially for priority 3 bugs when they are getting lowered to priority 4 as the shipping deadline approaches.
This also allows you you decide to ship with crashing bugs, if they occur only in really, really rare circumstances.
My 5 cents
I like to use the following:
Visualize each one falling on your head...
The beauty of this system is when you also visualize a truckload of sand being dumped on your head. Even though a system may have no huge issues, too many small issues can make it unusable as well.
In my opinion, most common categorization is A-B-C, eventually A-B-C-D. Ideally there should be a description for each severity agreed by all stakeholders. For example it could be like this:
Severity A or 'Critical' : defect that need to be fixed before the application can be released into production. Some part of application is not working at all or it can cause business or financial loss. There is no workaround.
Severity B or 'Major' : defect causes great deviation from the business requirements if released into production. Workaround is possible.
Severity C or 'Medium' : defect causes minimal deviation from the business requirements if released into production.
Severity D or 'Minor' or 'Cosmetic' : defect causes no deviation from the business requirements if released into production. It could be static texts, colors etc.
Additionally, bug can be categorized as a Showstopper. It means tester could not continue in his test. Usually showstopper has severity A but rarely it could be lover severity, depend on the situation.