Severity
Severity is how bad a defect's technical impact is — whether it crashes the whole application, blocks a core workflow, or is a minor cosmetic issue — independent of how urgently it needs fixing. A Severity 1 (critical) bug that only affects an unused feature might still sit behind a Severity 3 bug in the checkout flow when it comes to priority.
Severity is usually set by the tester who found the bug, since it's a technical judgment based on observed impact: does the app crash, does data get corrupted, is a core feature unusable, or is it purely cosmetic. Common scales run Critical/Blocker → High → Medium → Low, though exact labels vary by team.
The reason severity and priority are tracked as two separate fields, not one, is that they answer different questions and are set by different people for different reasons — severity by testers based on technical impact, priority by product or engineering leads based on business context. Confusing the two, or worse, merging them into one field, is a common way triage discussions go in circles.
