Defect Intake and Triage

A useful defect report explains what happened and where the team should look. Record the summary, project and reporter notes, then identify the reporter and corrective owner. The issue key gives the team a stable reference for discussion. The reported date helps a QA Engineer distinguish a new report from an older problem still waiting for attention.

Severity describes the seriousness of the defect. Critical, High, Medium and Low give the team a common vocabulary for triage. Task priority is a separate planning choice made when corrective work is assigned. A serious defect may require investigation before the Project Manager can decide exactly which task should move first.

• Report context. Write the observed behavior and the conditions needed to repeat it in the reporter notes. Identify the project before routing the report. Give the summary enough detail that an owner can recognize the problem without opening every attachment in the queue.
• Severity assessment. QA Engineer checks the report and selects the severity used by the team. The triage action requires an existing report marked Open with severity present. A report that no longer meets those conditions produces a failed-attempt receipt for investigation.
• Corrective ownership. QA Engineer assigns the person responsible for investigating the defect and retains the reporter separately. After successful triage, the report becomes Triaged. Project Manager can then organize the corrective task within the project’s work package and record the issue key in its description.

Agree what each severity means for your product and which examples help a reporter choose consistently. A customer-facing failure and an internal display defect may need different responses, but the team should be able to explain the assigned severity. Decide who corrects incomplete reports before the triage action runs.

Set a reporting convention for reproduction steps and expected behavior. Agree the identifier used when a task refers to a defect, and keep the issue key visible in that description. Decide who reviews failed triage receipts so an incomplete report does not disappear behind an apparently quiet queue. Explain the difference between reporting a problem and accepting its eventual fix during the first team rehearsal.

Use an illustrative checkout project where a discount is displayed incorrectly. The QA Engineer records what the tester entered, the displayed result and the expected behavior. The report belongs to the checkout project, carries a severity and starts as Open. The triage action moves it to Triaged and records the successful operation.

Repeat with severity omitted. The report should remain untriaged and the failed attempt should explain why. Then retry the report that already reached Triaged; it no longer meets the Open-state guard. Finally, have the Project Manager create a corrective task, include the issue key in its description and assign a Developer. The Developer should be able to identify the original report without guessing from similar task titles.

• Open Defect Reports — Reported defects grouped by their working state, with severity and ownership visible.
• Failed Operations — Unsuccessful triage attempts with the source reference and explanation needed for correction.

Continue through report and triage, then fix and verification once corrective work is assigned.