Q3 of 14 · JIRA

Describe the typical bug lifecycle / workflow in JIRA from creation to closure.

JIRAJuniorjirabug-lifecycleworkflowdefect-management

Short answer

Short answer: A bug moves through: Open → In Progress (developer picks it up) → In Review (PR) → Ready for QA → In Testing → Closed (if fixed) or Reopened (if still failing).

Detail

Workflows vary by team, but a standard QA-oriented bug lifecycle:

[Open]
   ↓ Developer starts work
[In Progress]
   ↓ PR raised
[In Review / Code Review]
   ↓ PR merged, deployed to test environment
[Ready for QA]
   ↓ QA picks it up
[In Testing]
   ↓ Passes verification
[Closed / Done]

   OR: testing reveals the fix is incomplete
[Reopened]
   ↓ Back to [In Progress]

Key JIRA fields that change during the lifecycle:

  • Assignee — moves from unassigned → developer → QA engineer
  • Fix Version — set when the bug is resolved, indicating which release it's in
  • Resolution — set on closure: Fixed, Won't Fix, Duplicate, Cannot Reproduce, By Design

QA's role at each stage:

  • Open — triage: confirm severity/priority, check for duplicates, ensure enough info to reproduce
  • Ready for QA — verify the fix in the test environment against the original reproduction steps AND regression-test related areas
  • Closing — close only if the specific bug is fixed; reopen if the fix is incomplete or introduced a regression

Reopened bugs should increment a re-open counter (custom field) — if a bug is reopened 3+ times, that signals a systemic issue with the fix quality or test coverage around that area.

// WHAT INTERVIEWERS LOOK FOR

The full lifecycle with statuses, QA's active role at each stage, and what the Resolution field means. The reopen-counter signal is a strong detail.