Bug Life Cycle in Software Testing: Defect States Explained

New

When a bug is detected in an application, it is assigned a status called 'New'. This implies that the defect found is yet be approved or studied. Following this, proper defect documentation is submitted to the development team so that they can reproduce and fix this defect. This 'NEW' defect further undergoes many status updates.

Teams that run automated suites add a triage step before a failure becomes a New defect. A failing test can point to a real product defect, a broken selector, an outdated test fixture, or a flaky test that passes on a rerun. The tester reproduces the failure manually or reruns the test in isolation first, then raises a defect only when the behavior repeats. This step keeps the bug life cycle free of noise that no developer can act on.

Key Takeaway: A defect is logged as New when a tester first detects and documents the bug for the development team, and a failing automated test should be reproduced or rerun in isolation before the failure is raised as a New defect.

Assigned

The defects assigned a status 'New' are further put through approval study by the test lead, project lead or development lead to check if it is valid or not. In case the bug is found valid it is assigned to a member of the development team by Test Lead/Project Lead or Manager. This is where the 'New' status is changed to 'Assigned'. The developer further fixes this defect and updates the status to 'Complete'.

Defect triage at this stage also sets two separate fields on the defect. Bug severity and priority mean different things: severity records the technical impact of the defect on the application, and priority records how urgently the team needs the fix. The two values move independently. A crash inside a rarely used screen can carry high severity and low priority, and a spelling mistake on the home page can carry low severity and high priority. Developers work the queue by priority, so a defect logged without both values often sits at Assigned longer than it should.

Key Takeaway: A bug moves from New to Assigned after a test lead, project lead, or development lead confirms the defect is valid and hands the defect to a specific developer to fix.

Open

At this stage, the development team begins scrutinizing the bug. After the 'Assigned' stage or at this level the bug is further categorized into states such as Duplicate/ Deferred/ Dropped/ Not a bug.

Key Takeaway: At the Open stage the development team examines the bug and can recategorise the defect as Duplicate, Deferred, Dropped, or Not a bug instead of moving straight to a fix.

Deferred

At times, the 'Assigned' bug status may be updated to 'Deferred' by the Project Manager or Project Lead .This happens due to the following reasons:

• If the bug is found to have a minor or not much important fix or if it is found during the end of the release.
• If the bug is not associated with the current build.
• If the defect seems to get fixed by the next release.
• Often the customer thinks of changing the requirement. Thus the status is changed to 'deferred' and planned to be fixed by next release.

Key Takeaway: A bug is marked Deferred when the fix is minor, the bug is found near the end of a release, the bug does not belong to the current build, or the customer changes the requirement, so the fix is planned for the next release.

Dropped Or Rejected

If the bug assigned or opened is logged due to certain misinterpretation (a reference to some old requirements or features) despite the system working in accordance with the specifications then the Team leads or developers marks such bug 'Rejected'. Along with the status update, the team lead should provide a specific reason for the above action.

Key Takeaway: A bug is marked Rejected when the report came from a misinterpretation of old requirements while the system works in accordance with the specifications, and the team lead must record a specific reason for the rejection.

Duplicate

The defect which is repeated twice or the one which is corresponding to the same concept of the bug is changed from an 'Opened' status to 'Duplicate' by the development team.

Key Takeaway: The development team changes a defect from Open to Duplicate when the same bug has already been logged or another report covers the same underlying problem.

Fixed

Once the necessary changes in the code are performed and verified by the developer then the status of the bug is changed to 'Fixed'. This bug is then passed onto the testing team.

Key Takeaway: A developer sets a bug to Fixed after making the code changes and verifying them, and the defect then passes to the testing team.

Pending Retest

Once the developer has fixed the defect he/she gives a part of the code in particular for retesting. Since the test is to be performed at the tester's end it holds a 'Pending Retest' status.

Key Takeaway: A bug carries the Pending Retest status after the developer returns the fixed code for retesting and before the tester performs that retest.

Retest

The Tester performs retesting at this stage to check the existence of defect fixed by the developer and alter the status as 'Re-test'.

Key Takeaway: In the Retest stage the tester retests the software to check whether the defect the developer fixed still exists.

Reopen

If the defect is found to exist fully or partially after the retest, then the tester updates it using defect retesting document with the status back to 'Reopen'. Again the bug is driven through the same procedure lifecycle to be fixed and completed again.

Key Takeaway: A bug goes back to Reopen when a retest shows the defect still exists fully or partially, and the bug then travels the same life cycle again to be fixed.

Verified

If the retest finds no defect in the software, the tester marks the bug as 'Verified'.

Key Takeaway: A tester marks a bug Verified when the retest finds no defect left in the software.

Closed

If the Tester or the Test Lead finds that the bug no longer exists then the status of the bug is changed to 'Closed'. This makes the end of the bug life cycle.

At times certain variations are found related to the statuses in the cycle. These are

• Cannot be fixed: If the bug is not technology supporting, or there is a certain problem of the product the status of a bug is termed as 'Cannot be fixed'. Sometimes this happens if the cost of fixing a bug is high.
• Need more information: If a developer is not able to coordinate with the tester by working according to the assigned steps then the developer changes the status to 'Need More Information'.

These stage names describe the defect model, and most teams now record them inside an issue tracker whose own fields carry the same meaning. Jira ships default statuses such as Resolved, Reopened, and Closed, and it stores Duplicate, Cannot reproduce, and Won't do as resolution values rather than as statuses. Map every stage in your process to one tracker status and one resolution before the project starts, so a report that counts open defects returns the same figure for every team.

Although most companies prefer to work on preventing defect which is more effective than decreasing the number of defects yet following a structured plan to remove bugs has proved to be helpful across many organizations.

Key Takeaway: A defect is marked Closed once the tester or test lead confirms the bug no longer exists, which ends the bug life cycle, and an AI coding agent can move a defect to Fixed but never to Closed.

How Do AI Coding Agents Change the Bug Life Cycle?

AI coding agents change who does the work at the Assigned and Fixed stages, and they add no new states to the bug life cycle. A human tester still retests and verifies every fix before a defect is Closed.

AI coding agents now act inside the bug life cycle, and they change who does the work at the Assigned and Fixed stages rather than adding new states. GitHub's Copilot coding agent documentation describes selecting Copilot as the assignee on a backlog issue. The agent then works on the task in the background and produces a pull request that a person reviews. The defect still moves from New to Assigned to Fixed. The developer reviews a proposed diff instead of writing the first one.

Error monitoring tools run the same pattern from the production side. Sentry documents a three step flow for its Seer agent on an issue: root cause analysis against the codebase, solution identification, and code generation that can optionally open a pull request. Sentry describes the flow as collaborative, and the user can give feedback at the root cause step, drop steps from the proposed solution, or take the change locally instead of opening a pull request. A defect that starts as a production error therefore reaches the Assigned stage with a candidate cause already attached.

Two rules keep the life cycle honest when an agent is involved. First, an agent-generated pull request does not move a defect to Verified. The fix still passes Pending Retest, Retest, and Verified, and a tester confirms that the original reproduction steps no longer fail. Second, record the agent as the source of the fix in the tracker the same way you record a developer, because reopen counts split by source are the only way to tell whether agent fixes hold. An agent can move a bug to Fixed. It cannot close one.

Key Takeaway: An AI coding agent can take an assignment and produce a candidate fix at the Assigned and Fixed stages, but the defect still passes Pending Retest, Retest, and Verified before a tester closes it.