01The common stages
| Stage | Owner | Meaning |
|---|---|---|
| New | QA | Reported, not yet looked at |
| Triaged | Tech lead / PM | Confirmed real, prioritised, assigned |
| In progress | Engineer | Being worked on |
| Fixed | Engineer | Code change merged, ready to verify |
| Verified | QA | Re-tested, confirmed fixed |
| Closed | QA / PM | No further action required |
Some teams add Reopened (verification failed), Won't Fix (intentional non-fix), or Duplicate (already tracked elsewhere).
02What QA owns vs what dev owns
QA owns: discovering, reporting clearly, verifying the fix.
Dev owns: triaging, assigning, fixing, providing enough context for QA to verify.
A clear lifecycle reduces the "is this still broken?" thrash that happens when stages are ambiguous.
03Linking defects to test cases
When a test case fails, link the failure to the defect — not the other way around. The case is the long-lived artefact; the defect is the work item that gets closed.
04Related
05Frequently asked questions
Where should defects live?
In your defect tracker (Jira, GitHub Issues, Linear), not in the test management tool. The test management tool links to the defect via external references.
Should every failed test become a defect?
No. Some failures are environmental, some are test data issues, some are flaky tests. Triage first; only confirmed product issues become defects.