Difference between Priority and Severity of a bug?

Priority: 
Priority defines the order in which developer should resolve a defect.This priority status is set by the tester while logging the defect through tool.

Priority can be of following types:

Priority 1 – Critical (P1): This has to be fixed immediately within 24 hours. This generally occurs in cases when an entire functionality is blocked and no testing can proceed as a result of this. Or in certain other cases if there are significant memory leaks, then generally the defect is classified as a priority -1 meaning the program/ feature is unusable in the current state.

 Priority 2 – High (P2): Once the critical defects have been fixed, a defect having this priority is the next candidate which has to be fixed for any test activity to match the “exit” criteria. Normally when a feature is not usable as it’s supposed to be, due to a program defect, or that a new code has to be written or sometimes even because some environmental problem has to be handled through the code, a defect may qualify for a priority 2.
Priority 3 – Medium (P3): A defect with this priority must be in contention to be fixed as it could also deal with functionality issues which is not as per expectation. Sometimes even cosmetic errors such as expecting the right error message during the failure could qualify to be a priority 3 defect.
Priority 4 – Low (P4): A defect with low priority indicates that there is definitely an issue, but it doesn’t have to be fixed to match the “exit” criteria. However this must be fixed before the GA is done. Typically, some typing errors or even cosmetic errors as discussed previously could be categorized in here. Sometimes defects with priority low are also opened to suggest some enhancements in the existing design or a request to implement a small feature to enhance user experience.

Severity:

It is the extent to which the defect can affect the software. In other words it defines the impact that a given defect has on the system.

Severity can be of following types:

• Critical / Show Stopper (S1): A defect that completely hampers or blocks testing of the product/ feature is a critical defect. An example would be in case of UI testing where after going through a wizard, the UI just hangs at one pane or doesn’t go further to trigger the function. Or in some other cases, when the feature developed itself is missing from the build.
• Major or Severe (S2): A major defect occurs when the functionality is functioning grossly away from the expectations or not doing what it should be doing. An example could be: Say that a VLAN needs to be deployed on the switch and you are using a UI template that triggers this function. When this template to configure VLAN fails on the switch, it gets classified as a severe functionality drawback.
• Moderate/ Normal (S3): A moderate defect occurs when the product or application doesn’t meet certain criteria or still exhibits some unnatural behavior, however the functionality as a whole is not impacted. For example in the VLAN template deploy above, a moderate or normal defect would occur when the template is deployed successfully on the switch however there is no indication being sent to the user.
• Low or Minor (S4): A minor bug occurs when there is almost no impact to the functionality, but is still a valid defect that should be corrected. Examples of this could include spelling mistakes in error messages printed to user or defects to enhance the look and feel of a feature.

Examples:

1. Let us assume a scenario where “Login” button is labeled as “Logen”:
   The priority and severity for different situations may be expressed as:-

·         For GUI testing: it is high priority and low severity

·         For UI testing: it is high priority and high severity

·         For functional testing: it is low priority and low severity

·         For cosmetic testing: it is low priority and high severity

2. Low Severity, Low Priority

Suppose an application (web) is made up of 20 pages. On one of the pages out of the 20 which is visited very infrequently, there is a sentence with a grammatical error. Now, even though it’s a mistake on this expensive website, users can understand its meaning without any difficulty. This bug may go unnoticed to the eyes of many and won't affect any functionality or the credibility of the company.

3. Low Severity, High Priority

·         While developing a site for Pepsi, by mistake a logo sign of coke is embedded. This does not affect functionality in any way but has high priority to be fixed.

·         Any typo mistakes or glaring spelling mistakes on home page.

4. High Severity, Low Priority

·         In case application works perfectly for 50000 sessions but beings to crash after higher number of sessions. This problem needs to be fixed but not immediately.

·         Any report generation not getting completed 100% - Means missing Title, Title Columns but having proper data enlisted. We could have this fixed in the next build but missing report columns is a High Severity defect.

5. High Severity, High Priority

·         Now assume a windows-based application, a word-processor let’s say. As you open any file to be viewed it in, it crashes. Now, you can only create new files but as you open them, the word-processor crashes. This completely eliminates the usability of that word-processor as you can’t come back and edit your work on it, and also affects one of the major functionalities of the application. Thus, it’s a severe bug and should be fixed immediately.

·         Let’s say, as soon as the user clicks login button on Gmail site, some junk data is displayed on a blank page. Users can access the gmail.com website, but are not able to login successfully and no relevant error message is displayed. This is a severe bug and needs topmost priority.