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.
Above priority and severity qualifiers can be different between either companies or projects but basically their value remains the same. Assigning a defect priority and severity is always subjective as the test engineer measures the impact from his point of view. Nevertheless he should always decide with care as the defect resolution time depends on this.
Which prioritization are you used to work with? Do developers take your defect priority into account?