9 programs
Choose the best training program according to your career.
Improve the performance of your business with our innovative Industrial Training Program.
Read More →
Our instructor-led training classes are designed to make you an expert.
Read More →
Real-life case studies are a great way to demonstrate your practical knowledge.
Read More →
Explore blogs, latest technologies and industry updates with practical examples.
Read More →
Browse all available training programs and choose the right one for your career.
Read More →Know more about who we are and what we stand for.
Discover our mission to equip individuals with essential IT skills and industry expertise.
Read More →Learn, practice and plan your career — bilkul free.
Book a free video counselling session and pick the right course for you.
Read More →Download the bug life cycle PDF from Uncodemy: defect states from New to Closed, special states, responsibilities and a workflow diagram.
This page offers Uncodemy's bug life cycle guide as a PDF download. The bug life cycle, also called the defect life cycle, describes the states a defect passes through from the moment it is found until it is closed. The guide explains each state, who is responsible, the special states such as rejected, deferred and reopened, and how teams adapt the workflow.
Three quick-access entry points into the same bug life cycle PDF: the full guide, the states and special states reference, and the workflow plus responsibilities pack. All PDFs on this page are free to download. No form is required.
The complete guide to the bug life cycle — what it is, typical states, special states, a typical flow, responsibilities by role and the measures teams watch.
Reference card for the typical states (New, Assigned, In progress, Fixed, Verified/Closed, Reopened) and the special states (Rejected, Duplicate, Deferred, Cannot reproduce, Blocked) with what should happen next.
The workflow as text (main path + side paths), responsibilities by role (tester, lead, developer, product owner), the measures teams watch and an example: one defect through the cycle.
All three download buttons open the same bug life cycle PDF file. By downloading, you agree to our Privacy Policy. These PDFs are study material only — not a certificate or job guarantee.
The bug life cycle is the set of states a defect moves through during its life in a tracking tool, together with the rules for moving between them. It exists so that everyone knows the status of every defect, who is responsible for the next action and what has been decided. Without a defined cycle, bugs are lost, fixed twice, closed without verification or argued about in chat. The exact names and steps vary between organisations and tools, but the pattern is common: a tester reports, a lead triages, a developer fixes, a tester verifies and the defect is closed.
| State | Meaning | Usually moved by |
|---|---|---|
| New | A defect has been reported and is waiting for review | Tester |
| Assigned or Open | Accepted as valid and assigned to a developer | Test or development lead |
| In progress | The developer is working on a fix | Developer |
| Fixed or Resolved | The developer believes the defect is fixed and delivered in a build | Developer |
| Ready for retest | A build containing the fix is available for verification | Developer or release process |
| Verified or Closed | The tester confirmed the fix works and no regression appeared | Tester |
| Reopened | The fix did not work or the issue came back | Tester |
| State | When it is used | What should happen next |
|---|---|---|
| Rejected or Not a bug | Behaviour is as designed, or the report is invalid | Tester reviews the explanation and either accepts or discusses with the lead |
| Duplicate | The same defect is already reported | Link to the original and close this report |
| Deferred or Postponed | A valid defect that will be fixed in a later release | Record the target release; review at planning |
| Cannot reproduce | The developer cannot see the problem with the given steps | Tester adds details, environment and recordings, or retests |
| Blocked | The fix or retest depends on something else | Resolve the dependency; note the reason |
A tester finds a defect, writes a report and saves it as New. The test lead reviews it, confirms it is valid and not a duplicate, sets severity and priority and assigns it to a developer, which moves it to Assigned. The developer investigates and, once working on it, marks it in progress. After the change is committed and built, the developer marks it Fixed and often adds a note about the cause and the change. The tester retests on the new build, repeating the original steps and checking nearby behaviour. If the problem is gone, the defect is Closed. If it remains, the tester marks it Reopened with a comment and the cycle repeats from assignment.
A simple diagram showing the main path and the common side paths. Teams adapt the names to their tool.
| Measure | What it can reveal |
|---|---|
| Time in each state | Bottlenecks, such as defects waiting for retest |
| Reopen rate | Quality of fixes or of reproduction steps |
| Rejected rate | Clarity of requirements or tester training needs |
| Age of open defects | Backlog health |
| Defects by severity and module | Where quality problems cluster |
| Day | State | What happened |
|---|---|---|
| Mon | New | Tester reports that the coupon field accepts expired codes |
| Mon | Assigned | Lead confirms, sets severity High and assigns to a developer |
| Tue | In progress | Developer finds that the expiry date check uses the wrong time zone |
| Wed | Fixed | Fix merged and included in build 142 |
| Thu | Reopened | Tester finds codes expiring at midnight still work in one region |
| Fri | Closed | Second fix verified on build 145 with regression checks |
Ready to run a defect workflow your team can actually follow? Explore Uncodemy's Software Testing course or book a free demo and learn from industry trainers.
