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.