Severity and priority given to a defect completely depends on the defect.
1.Suppose a product is to be launched very soon and there is a spelling mistake in the product name itself, then in this case priority is high(i.e. the product can't be launched with wrong product name itself) and severity is low(i.e. it won't affect the real usability of the product as such).
2.In another example, suppose in a product one new functionality (say email functionality) is to be added in the next version and that new functionality doesn't work right. Here we can give severity as high(because it needs to be fixed for its right functionality) and priority as low(as it will be added in the next version, so no hurry).
Priority :- How quickly we need to fix the bug? Or How soon the bug should get fixed?
Severity : - How much the bug is effecting the functionality of the application or how deadly can it be for the application under consideration.
(1) High Priority and Low Severity
If a company logo is not properly displayed on their website.
(2) High Priority and High Severity
Suppose you are doing online shopping and filled payment informations, but after submitting the form, you get a message like "Order has been cancelled." Normally high severity bugs comes with high priority.
(3) Low Priority and High Severity
If we have a typical scenario in which the application get crashed, but that scenario exists rarely.
(4) Low Priority and Low Severity
There is a mistake like "You have registered success" instead of successfully, success is written.Basically general spelling mistake kind of thing which is not expected.
High: Fix the defect immediately. A core functionality fails or test execution is completely blocked.
Medium: Fix the defect soon. An important functionality fails but we don't need to test it right away and we have a workaround.
Low: Don't fix this defect before the high and medium defects are fixed but don't forget this defect.
Defect priority indicates the impact on the test team or test planning. If the defect blocks or greatly slows down test execution, you might want to select the highest grade for the defect priority.
Critical: A core functionality returns completely invalid results or doesn't work at all.
Important: This defect has impact on basic functionality.
Useful: There is impact on the business, but only in a very few cases.
Nice to have: The impact on the business is minor. Any user interface defect not complicating the functionality often gets this severity grade.
Defect severity indicates the impact on the business of the client. If important functionality is blocked or if that functionality functions incorrectly, the test engineer mostly selects the highest defect severity.
How serious the defect is, is described in terms of severity. It is classified in to 4types.
1. FATAL Sev1 S1 1
2. MAJOR Sev2 S2 2
3. MINOR Sev3 S3 3
4. SUGGESION Sev4 S4 4
It is all the problems are related to navigational blocks or unavailability of functionality then such types of problems are treated to be FATAL defect.
Note: It is also called as show stopper defects.
It at all the problems are related to the working of the features then such types of problems are treated to be MAJOR defects.
It at all the problems are related to the look and feel of the application then such types of problems are treated to be MINOR defects.
If at all the problems are related to the value of the application then such types of problems are treated to be suggestions.
The sequence in which the defects have to be rectified is described in terms of priority. It is classified in to 4 types.
Usually the FATAL defects are given CRITICAL priority, MAJOR defects are given HIGH priority, MINOR defects are given MEDIUM priority and SUGGITION defects are given LOW priority sent depending upon the situation the priority may be changed by the project lead or development lead.
Ex: - Low Severity High Priority Case:
In the case of customer visit all the look and feel defects, which are usually less savior, are given highest priority.
High Severity Low Priority Case:
If at all some part of the application is not available because it is under development still the test engineer will treat team as FATAL defect, but the development lead will give less priority for those defects.
Priorityriority ask the question like "When bug should be fixed?"
Severity:severity is nothing but the impact of the bug.
Severity comes under three category
1>Criticalefect will cause damage/crash to the product.
e.g.Suppose you are registering an examination form.After filling the form when you submit the form it will show a message like ,your registration process is failed.please try after some time.
we can say it as high priority and high severity problem.
2>Major:The bug/defect could cause a harm to the product.
e.g.Suppose there is a bug in the intermediate module which has no effect to the system for a single user ,if suppose more than thousands of user access at the same time it may happen that the system will crash/damaged.
It comes under low priority and high severity.
3>minor:It will not cause any harm to the product or system.
e.g. spelling mistake type of things.
Priority: This term explains when to to fix bug, i.e. can bug be deffered or it requires immediate attention.
Severity : This term explains how severe the bug is? i.e. the impact of that bug. How much and how long it affects the system.
Different bug tracking system(Accurave, Bugzila) uses different level of priority and severity.
It may vary from very low to very high, Immediate to ignore or fix later,minor to critical to minor etc. But its combination is important as combination says both "what is the impact?" and "when to fix?"
One scenario for this combination is explained by Nilanjan very well