Defects and bug reports

Finding a defect is half the job. The other half is reporting it so that people understand it, decide on it quickly and fix it. Interviewers ask about defects in almost every testing round: the life cycle, severity versus priority, what a good bug report holds, and what you do when a developer rejects your bug. This article covers each of these with examples.

The defect life cycle

A defect moves through a set of statuses in a bug tracker (a tool where the team records bugs and tasks) such as Jira. Names differ between teams, but the flow is similar everywhere.

The tester logs the defect as New. After triage (a review of new bugs where the team decides what to do with each one), a developer takes it (Assigned or Open). The developer fixes it and names the build that holds the fix (Fixed). The tester repeats the original steps on that build (the version of the software that holds the fix) to see if the bug is gone (Retest). If the fix works, and a short regression check around it passes, the defect is Closed. If the same failure still happens, it is Reopened with new evidence and goes back to the developer. If the retest shows a different problem, close the original and log a new defect linked to it.

Triage can also end a defect early: Rejected means it is not a defect (the product works as designed), Duplicate means it was already logged, and Deferred means it is real but the team agrees to fix it in a later release.

Severity and priority

Severity is how much the defect hurts the system or its users. The tester usually proposes it. Priority is how soon it must be fixed, based on business needs. The product owner or the triage meeting usually sets it. Because they are judged separately, all four combinations exist:

• High severity, high priority: no customer can pay at checkout.
• High severity, low priority: an admin report used once a year crashes, and the page is being replaced next month.
• Low severity, high priority: the company name is misspelt on the home page.
• Low severity, low priority: a label is 2 pixels out of line on a rarely used settings page.

Priority can change. The yearly report bug becomes urgent when the year end comes.

A bug report a developer can act on

A good report lets a developer reproduce the problem (make it happen again) without asking you anything. It has a specific title in the form "where: what happens, under which condition", for example "Checkout: Place order returns error 500 when a coupon is applied to a cart with 2 or more items" (error 500 is a code meaning the server failed). It names the environment (the server and setup where you tested) and the build, gives exact steps and test data, states the expected and actual result with the exact error message, and attaches evidence such as a screen recording, logs or a request ID (a unique ID for one call to the server, so developers can find it in the logs). It also says how often the problem happens and explains the severity in terms of user impact.

The most useful extra line is a narrowing one: "without a coupon the order succeeds". It can save the developer hours. Leave capital letters and words like "URGENT" out; urgency belongs in the priority field.

When a developer rejects your bug

First check yourself: retest on the latest build and read the requirement again. If you were wrong, say so. "Cannot reproduce" usually means a difference in environment, data or steps, so compare them and reproduce it together on a short call. "Works as designed" means you need the requirement. If the requirement is unclear, the product owner decides the expected behaviour, not the tester or the developer. Record the decision in the ticket (the bug's record in the tracker).

Triage, leakage and hidden defects

Defect triage is a regular meeting where the product owner, the development lead and the test lead decide, for each new defect, whether it is valid, its priority, who fixes it and in which release. Near a release it may happen daily.

Defect leakage describes defects that a test phase missed and someone found later, for example users in production (the live system that real users use). ISTQB calls such a defect an escaped defect. One common formula is defects found after the phase divided by defects found in the phase, times 100; teams define it differently, so state yours. When a bug escapes, add a test for it and fix the reason it was missed.

A masked defect is hidden by another defect that blocks the path to it. If the "Export to PDF" button always fails, nobody sees that the PDF layout cuts off a column until the button is fixed. A latent defect sits in the software without failing because the triggering condition has not happened yet, such as a date bug that only shows on 29 February.

How to answer in an interview

Walk through the life cycle in order and name who acts at each step. For severity and priority, give one example for each combination and say who sets each value. For a rejected bug, show that you check yourself first and keep the discussion about users.

Common mistakes

• Saying the tester sets priority.
• Logging a new bug when the same failure comes back after a fix, which loses the history.
• Vague titles such as "search not working".

Recap

New, Assigned, Fixed, Retest, then Closed or Reopened. Severity is impact and priority is urgency. A good report can be reproduced without questions. Disagreements are settled with evidence and the product owner's decision.