Learner can identify the required parts of a strong bug report and correctly distinguish severity from priority.
What makes a great bug report
What makes a great bug report
A bug report is a formal record of a defect found during testing. Its goal is to give the development team everything they need to reproduce, understand and fix the problem. Every strong bug report contains: (1) a clear, descriptive title; (2) reproducible steps to reproduce (STR) — numbered, from the very first click; (3) actual result — what the system does; (4) expected result — what it should do; (5) environment — browser, OS, app version, device; (6) severity; (7) priority; and optionally (8) attachments such as screenshots, logs or video.
The most common beginner mistake is writing vague or incomplete steps to reproduce. A developer who cannot reproduce the bug cannot fix it. Steps must start from a known state and be detailed enough for anyone to follow.
Severity describes the technical impact of the defect on the system — it is assessed by QA. Priority describes the urgency of fixing it from a business perspective — it is owned by the product manager or management. These two dimensions are independent, which leads to classic crossover cases.
High severity / low priority example: a crash occurs on a browser used by 0.1% of users two weeks before a major release — the system breaks completely (high severity) but the team may defer the fix (low priority). Low severity / high priority example: the company logo is displayed in the wrong colour on the homepage — it does not break any functionality (low severity) but the CEO wants it fixed before the press conference today (high priority).
Lesson notes
What makes a great bug report
A bug report is a formal record of a defect found during testing. Its goal is to give the development team everything they need to reproduce, understand and fix the problem. Every strong bug report contains: (1) a clear, descriptive title; (2) reproducible steps to reproduce (STR) — numbered, from the very first click; (3) actual result — what the system does; (4) expected result — what it should do; (5) environment — browser, OS, app version, device; (6) severity; (7) priority; and optionally (8) attachments such as screenshots, logs or video.
The most common beginner mistake is writing vague or incomplete steps to reproduce. A developer who cannot reproduce the bug cannot fix it. Steps must start from a known state and be detailed enough for anyone to follow.
Severity describes the technical impact of the defect on the system — it is assessed by QA. Priority describes the urgency of fixing it from a business perspective — it is owned by the product manager or management. These two dimensions are independent, which leads to classic crossover cases.
High severity / low priority example: a crash occurs on a browser used by 0.1% of users two weeks before a major release — the system breaks completely (high severity) but the team may defer the fix (low priority). Low severity / high priority example: the company logo is displayed in the wrong colour on the homepage — it does not break any functionality (low severity) but the CEO wants it fixed before the press conference today (high priority).