47 lines
1.6 KiB
Markdown
47 lines
1.6 KiB
Markdown
# Bug Triage
|
|
|
|
## Purpose
|
|
|
|
Frame a defect clearly before or during debugging so the team understands impact, reproduction, suspected scope, and next actions.
|
|
|
|
## When to use
|
|
|
|
- A bug report arrives with incomplete detail
|
|
- A failing test or regression needs initial framing
|
|
- Multiple issues compete for attention and severity matters
|
|
- You need a reliable reproduction path before deeper debugging
|
|
|
|
## Inputs to gather
|
|
|
|
- Reported symptoms, expected behavior, and actual behavior
|
|
- Reproduction steps, environment, and frequency
|
|
- User impact, severity, and likely affected surfaces
|
|
- Recent changes, logs, or tests that may be related
|
|
|
|
## How to work
|
|
|
|
- Turn vague symptoms into a concrete problem statement.
|
|
- Reproduce the issue when possible and tighten the reproduction steps.
|
|
- Separate confirmed facts from assumptions.
|
|
- Estimate impact and likely blast radius before diving into fixes.
|
|
- Identify the next best debugging step if root cause is not yet known.
|
|
|
|
## Output expectations
|
|
|
|
- Clear bug statement and reproduction status
|
|
- Impact and severity assessment
|
|
- Suspected scope or likely component area
|
|
- Recommended next debugging or fix step
|
|
|
|
## Quality checklist
|
|
|
|
- The issue is described in observable terms rather than guesses.
|
|
- Reproduction details are specific enough to be reused.
|
|
- Impact is clear enough to prioritize intelligently.
|
|
- Unknowns are named instead of hidden.
|
|
|
|
## Handoff notes
|
|
|
|
- Record environment details and whether the issue is deterministic, intermittent, or unconfirmed.
|
|
- Pair with debugging workflow once the problem is framed well enough to investigate deeply.
|