Based on pre-defined severity descriptions, the test team should assign the severity of a defect objectively. For example a “severity one” defect may be defined as one that causes data corruption, a system crash, security violations, etc.
Severity levels should be defined at the start of the project so that they are consistently assigned and understood by the team. This foresight can help test teams avoid the common disagreements with development teams about the criticality of a defect.
In large projects, it may also be necessary to assign a priority to the defect, which determines the order in which defects should be fixed. The priority assigned to a defect is usually more subjective as it may be based on input from users regarding which defects are most important, resources available, risk