QA glossary
What is bug triage?
Bug triage is the regular review of newly reported defects to decide, for each one, whether it is real, how severe it is, how soon it must be fixed and who will fix it. It turns a raw pile of reports into an ordered backlog a team can act on.
An example from QA practice
Testers log 40 new reports against a release candidate. In a 30-minute triage, the QA lead, the product owner and a developer go through them. Six are duplicates and get merged. Three cannot be reproduced and go back to the reporter for a screen recording. Two break checkout and are marked critical for a hotfix. The rest are ranked and scheduled.
Severity is not priority
Severity is how badly a defect hurts the system. Priority is how soon the business needs it fixed. A typo in the homepage headline is low severity and high priority. A crash in an admin report that two people open once a quarter can be the opposite. Triage settles both, so developers are not left guessing.
Triage is only as good as the reports it reads. Each one needs steps to reproduce, the expected and actual result, the environment, and evidence such as a screenshot or video. Without those, the meeting turns into a discussion about what the reporter meant.
How BetterQA does it
Our engineers log defects in BugBoard, the defect tracker we built. A screenshot or video becomes a bug report with steps to reproduce and the evidence attached, so a triage call is spent on decisions, not on working out what happened.