The Bug Lifecycle - New to Closed
The bug lifecycle defines the standard states a defect moves through from initial discovery to final resolution - and the transitions between states. Without a defined lifecycle, defects get lost, disputed, or fixed without proper verification. A well-defined and consistently enforced bug lifecycle is a hallmark of mature QA practice and is one of the most directly visible indicators of QA process health to management and auditors.
Standard Bug Lifecycle States
- New: QA tester discovers and logs a defect in the tracking system (Jira). Defect is newly created and has not yet been reviewed by anyone
- Open / Assigned: The defect has been reviewed, confirmed as valid, and assigned to a developer for investigation and fixing. The QA Lead or developer triages the defect at this stage
- In Progress / Being Fixed: The developer is actively working on the fix. Some teams use this state, others go directly from Open to Fixed
- Fixed / Resolved: The developer has implemented a fix and updated the defect ticket with: what was changed, the build number containing the fix, and any notes on the fix approach
- Ready for Retest: The fixed build has been deployed to the test environment and the defect is ready for QA verification. Critical state - QA should not retest until this state is set
- Retest In Progress / Reopened: If the retest fails (the defect is still present or the fix introduced a new issue), the defect is Reopened and goes back to Assigned state. Document exactly what the retest found
- Verified / Closed: The fix is confirmed to resolve the original defect. QA sets to Closed after successful retest AND targeted regression testing to confirm no side effects
- Deferred: The defect is acknowledged but will not be fixed in this release. Requires explicit business sign-off. Must be re-evaluated for every future release
- Rejected / Not a Bug: The developer (or product team) determines the reported behavior is working as intended, or the bug cannot be reproduced. QA may escalate rejected bugs with evidence if they disagree
Why Every State Matters
The most dangerous gaps in the bug lifecycle are: defects that get 'Fixed' by developers but never reach 'Ready for Retest' state (so QA never knows to verify them), and defects that QA 'Closes' without doing regression testing (potentially closing a defect whose fix broke something else). Establish clear SLAs for each lifecycle stage: Open defects should be triaged within 24 hours (critical) or 48 hours (high/medium). Fixed defects should be deployed to the test environment within one business day. QA should complete retest within one business day of Ready for Retest. These SLAs, when measured, reveal bottlenecks - long average time at 'Fixed' stage means the build-and-deploy process is slow; long time at 'New' stage means triage is backlogged.
Every bug follows a lifecycle - track state transitions for quality metrics
Tip
Tip
Practice The Bug Lifecycle New to Closed in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of The Bug Lifecycle New to Closed 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 The Bug Lifecycle New to Closed is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- The bug lifecycle defines the standard states a defect moves through from initial discovery to final resolution - and the transitions between states.
- New: QA tester discovers and logs a defect in the tracking system (Jira). Defect is newly created and has not yet been reviewed by anyone
- Open / Assigned: The defect has been reviewed, confirmed as valid, and assigned to a developer for investigation and fixing. The QA Lead or developer triages the defect at this stage
- In Progress / Being Fixed: The developer is actively working on the fix. Some teams use this state, others go directly from Open to Fixed