Beginner-Friendly Topic
Take your time - it's perfectly normal to re-read this topic 2-3 times. Try the interactive code editor below to run code yourself. Use the Q&A section to check your understanding before moving on. You've got this! 🚀
Bug Lifecycle & Defect Management
Every bug follows a structured lifecycle from discovery to closure. Understanding the defect lifecycle enables effective communication between testers, developers, and project managers. Mismanaging the bug lifecycle causes defects to be lost, mis-prioritized, or closed prematurely - all of which lead to production failures.
The Standard Bug Lifecycle
- New: Tester discovers and logs the defect. Bug report is created with all required details.
- Assigned: Bug manager or team lead assigns the defect to a developer for investigation.
- Open: Developer acknowledges the bug and begins investigation/fixing.
- Fixed: Developer has fixed the code and marked it resolved. Code is in the build ready for testing.
- Retest: Tester verifies the fix on the same environment with the same steps that originally reproduced the bug.
- Verified: Tester confirms the fix works. Bug is not reproducible with the original steps.
- Closed: Bug verified fixed and no regression found. Closed by the tester or test lead.
- Rejected: Developer determines it is not a bug (by design, not reproducible, duplicate). Tester reviews and either agrees or escalates.
- Deferred: Valid bug but fixed in a future release due to low priority or missed deadline.
- Reopened: Tester finds the fix didn't work or the bug reappeared. Bug goes back to Assigned.
Bug Lifecycle State Transitions
// Bug Lifecycle State Machine
// Each state transition has conditions and responsible role
const bugLifecycle = {
NEW: {
actor: "Tester",
actions: ["Assign → developer", "Reject → if duplicate/by design"],
nextStates: ["ASSIGNED", "REJECTED"]
},
ASSIGNED: {
actor: "Dev Lead",
actions: ["Start working → Open", "Defer → later sprint", "Reject → not a bug"],
nextStates: ["OPEN", "DEFERRED", "REJECTED"]
},
OPEN: {
actor: "Developer",
actions: ["Fix the code → Fixed", "Cannot reproduce → need more info"],
nextStates: ["FIXED", "NEED_INFO"]
},
FIXED: {
actor: "Developer",
actions: ["Notify tester → deploy to test environment"],
nextStates: ["RETEST"]
},
RETEST: {
actor: "Tester",
actions: [
"Fix verified → Verified/Closed",
"Fix doesn't work → Reopened",
"New regression found → New bug opened"
],
nextStates: ["VERIFIED", "REOPENED"]
},
VERIFIED: { actor: "Tester", nextStates: ["CLOSED"] },
CLOSED: { actor: "Test Lead/PM", nextStates: [] },
REOPENED: { actor: "Developer", nextStates: ["OPEN"] },
REJECTED: {
actor: "Tester reviews",
actions: ["Agree → Close", "Disagree → Escalate for clarification"],
nextStates: ["CLOSED", "OPEN"]
},
DEFERRED: {
actor: "PM",
actions: ["Prioritize for next sprint → Assigned"],
nextStates: ["ASSIGNED"]
}
};
// Real scenario - tracking a critical login bug:
// Day 0: Tester finds login fails on Firefox → Status: NEW
// Day 0: Test Lead assigns to DevBob → Status: ASSIGNED
// Day 1: DevBob confirms it's a CSS focus trap → Status: OPEN
// Day 2: DevBob fixes and deploys to staging → Status: FIXED
// Day 2: Tester retests on Firefox → Status: RETEST
// Day 2: Bug is gone, regression check clear → Status: VERIFIED → CLOSEDCommon Mistakes
- Closing bugs without retesting - 'Developer says it's fixed' is not verification; the tester must confirm independently
- Not reopening bugs that recur - if a closed bug appears again in production, it must be reopened, not filed as a new bug (loses history)
- Accepting all rejections - if a developer rejects a valid bug as 'by design', escalate with the specification to prove it's a defect
- Not tracking deferred bugs - deferred defects must be tracked in the backlog; they don't disappear; they become next sprint's priority
Tip
Tip
Practice Bug Lifecycle Defect Management in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Every bug follows a lifecycle - track state transitions for quality metrics
Practice Task
Note
Practice Task - (1) Write a working example of Bug Lifecycle Defect Management from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Bug Lifecycle Defect Management is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Every bug follows a structured lifecycle from discovery to closure.
- New: Tester discovers and logs the defect. Bug report is created with all required details.
- Assigned: Bug manager or team lead assigns the defect to a developer for investigation.
- Open: Developer acknowledges the bug and begins investigation/fixing.