Bug lifecycle or Defect lifecycle indicates the complete lifecycle of a bug during a test cycle. It defines the stages a defect/bug goes through right from when it was found till it gets closed. It has various status like new, open, assigned, fixed, closed and reopen.
Below points will summarize entire Bug Lifecycle or Defect Lifecycle:
- Once Test Engineer gets a bug the status of the bug is in New or Open status.
- This bug is then reported to the concerned person and status is changed to Assigned.
- The developer does the necessary code changes and fix the bug and changes the status to Fixed.
- Once the bug is fixed, Test Engineers retest the bug once again and changes the status accordingly that is Close if the defect is fixed properly or Re-open if the defect still exists.

Some other Bug status apart from the above four are as follows:
- Invalid: In this case developers do not accept it as a bug. This might happen if Test Engineers misunderstands the requirements or the Developer misunderstands the requirements
- Duplicate: If the same bug has been reported more than once.
- Not Reproduceable: Developer accepts it as a bug but not able to reproduce it due to some reasons. A bug cannot be reproduced for many reasons like –> Improper Bug report, Environment Mismatch, Data Mismatch, Build Mismatch or Inconsistent Bug (Bug which pops out suddenly and not happening all the times)
- Can’t be Fixed: Developer accepts the bug and they are able to reproduce the bug but cannot fix it due to reasons like –> Bug is in the core of the code which is too risky to fix when release date is very near, No technology support is there to fix the issue and if the cost of fixing the bug is more than keeping it.
- Deferred: Developer accepts the bug and able to reproduce it but postposing the fix to future releases. The developer might defer it due to reasons like Time Constraint or it may have major effect.
- RFE: It stands for Request for Enhancements. This are the enhancements or the suggestions given towards the application.
What is the difference between Severity and Priority while fixing a Bug?
- Severity: Severity defines the effect of the Bug on the applications. Different types of severity levels are -> Blocker/Showstopper, Critical, Major, Minor
- Priority: Which bugs should be fixed first. Different types of Priority levels are -> Urgent, High, Medium and Low
Similar terminologies related to Defect or Bug in Software Engineering:
- Defect: Deviation from Requirement
- Bugs: Informal name for Defect
- Error: Mistakes made in code (Terms typically used by developers or Automation Test Engineers)
- Issue: When customer faces problem in application
- Failure: Defects lead to failures in application
Bug Report Template should more or less contain the following fields mentioned below:
- Bug Name/ID
- Test Case Name
- Module Name
- Requirement Number
- Status
- Date
- Reporter
- Assigned To
- Severity: Blocker/Critical/Major/Minor
- Priority: Urgent/High/Medium/Low
- URL
- OS & Browser
- Test Data
- Build Number
- Attachment and Screenshots
- Brief Description
- Steps To Reproduce
- Observations
So that’s it for this blog. I hope you find this blog informative and useful. For all the latest blog post updates please follow our Facebook and Instagram page. To know more about other stuff in Software engineering like Agile Methodology please check our earlier blogs.