Defect Priority

We use this to ... so that we can ...

Defect Priority is defined as the order in which a defect should be fixed. The Higher the priority, the sooner it will be fixed.

Any defect that results in the System/Application being unusable is given a higher priority than those that cause minor functionality failures.

A defect Priority is associated with scheduling.

Similar to Severity classifications, the Test Analyst will initially determine the Priority level of the defect based on a combination of their own system knowledge and the severity of the defect.

However, this determination should be supported by conversations with the Devs, BAs, Business SMEs or Product Owner to correctly understand the impact of the defect if not properly prioritised.

Blocker

Any defect that causes testing to be completely blocked with no options or workarounds to proceed.

Critical

To be fixed immediately within 24 hours. This priority is for defects with a Critical severity unless re-prioritised by Product Owner.

High

The defect must be resolved within the sprint it has been identified within or prior to Production Release. Defects classified as Major Severity fall into this category unless re-prioritised by the Product Owner.

Medium

To be resolved prior to production Release unless the defect has been accepted by Business Owner

Low

To be resolved prior to Production Release, however, can be moved to backlog for a later release.

Last updated