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.
0 comments:
Post a Comment