Priority and Severity

Sr.	Priority	Severity
1	It is associated with schedule to resolve e.g. out of many issues to be tackled, which one should be addressed first by the order of its importance or urgency.	It is associated with benchmark quality or adherence to standard. It reflects harshness of a quality expectation.
2	Is largely related to Business or Marketing aspect. It is a pointer towards the importance of the bug.	Is related to technical aspect of the product. It reflects on how bad the bug is for the system.
3	Priority refers to how soon the bug should be fixed.	Severity refers to the seriousness of the bug on the functionality of the product. Higher effect on the functionality will lead to assignment of higher severity to the bug.
4	Priority to fix a bug is decided in consultation with the client.	The Quality Assurance Engineer decides the severity level. It is decided as per the risk assessment of the customer.
5	Product fixes are based on 'Project Priorities.	Product fixes are based on Bug Severity.

1) Generally speaking, a "High Severity" bug would also carry a "High Priority" tag along with it. However this is not a hard & fast rule. There can be many exceptions to this rule depending on the nature of the application and its schedule of release. 

2) High Priority & Low Severity: A spelling mistake in the name of the company on the home page of the company’s web site is certainly a High Priority issue. But it can be awarded a Low Severity just because it is not going to affect the functionality of the Web site / application. 

3) High Severity & Low Priority: System crashes encountered during a roundabout scenario, whose likelihood of detection by the client is minimal, will have HIGH severity. In spite of its major affect on the functionality of the product, it may be awarded a Low Priority by the project manager since many other important bugs are likely to gain more priority over it simply because they are more visible to the client.