6.9Key Takeaways

• Severity is technical impact (assessed by QA). Priority is business urgency (set by product/management).
• Keep them as separate fields in your bug tracker — never collapse into one scale
• High severity does not automatically mean high priority, and vice versa
• A QA engineer who conflates severity and priority will misprioritize the backlog
• Triage meetings are where severity meets priority — present your findings clearly and let the team decide

Interview Talking Point: "I treat manual testing as a thinking discipline, not a task to automate away. I use session-based exploratory testing with charters and time boxes to systematically find issues that scripted tests miss. When I file a bug, I include a minimal reproduction, environment details, and a clear severity/priority split — because a bug report that a developer can reproduce in under two minutes gets fixed in hours, not weeks."