- Software Testing Tutorial
- Software Testing - Home
- Software Testing - Overview
- Software Testing - Defect Management
- Software Testing - Life Cycle
- Software Testing - Bug Life Cycle
- Software Testing - Myths
- Software Testing - QA, QC & Testing
- Software Testing - Environment
- Software Testing - Test Plans
- Software Testing - Strategies
- Software Testing - Steps
- Software Testing - Test Scenarios
- Software Testing - ISO Standards
- Software Testing - Types
- Software Testing - Methods
- Software Testing - Metrics
- Software Testing - Levels
- Software Testing - Documentation
- Software Testing - Estimation Techniques
- Software Testing - Test Data Generation
- Software Testing - 7 Principles
- Software Testing - Severity & Priority
- Software Testing - Test Script
- Software Testing - Defect Density
- Software Testing Useful Resources
- Software Testing - Quick Guide
- Software Testing - Useful Resources
- Software Testing - Discussion
Software Testing - Bug Life Cycle
In the world of Software Testing, the Bug life Cycle or a Defect life cycle describes the state of a defect or a bug. With respect to situations, the state of defect or bug also changes.
What is a Defect or Bug?
A bug (also known as defect) is an inaccuracy in the application that is introduced while a product or an application is being developed. This results in the product or the application not working as expected. In other words, a bug or defect causes the deviation from the actual to expected behavior of the product or the application.
No product or application is designed without a defect or a bug. So it is the primary responsibility of all the testers to detect as many defects (prominently in the early phases of software development) as possible so that the product or the application under test is delivered with quality. However, bugs or defects can be detected by both developers and testers.
Thus a defect or a bug is essential to maintain the quality of the application or the product. The return on investment received on a defect or a bug is also high. A defect or a bug creates effective communication and coordination among the team members who work towards fixing the defect or the bug, ultimately catering to the end user requirements.
What is a Defect or Bug Life Cycle?
Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle through during its lifetime. It varies from organization to organization and also from project to project as it is governed by the software testing processes, application being tested, and the tools being used for testing.
A defect or a bug life cycle is basically the drive of the defect or bug across its lifetime. It starts right from the introduction of a new defect or bug till its closure by the tester. The path and stages of defect or bug life cycle followed in various organizations or teams differ from one another. This is because of the absence of a uniform testing process, procedure, tool, development methodology, environment that is followed across various companies, and projects.
Following a defect or bug life cycle is essentially beneficial for both the developers and the testers. The primary purpose of having a defect or bug life cycle is to develop a clear communication and coordination among teams, thus ultimately achieving a quicker fix to a defect or a bug.
What is a Defect or Bug Status?
The defect or bug status denotes the present condition of the defect or the bug and its advancement. Thus a defect or bug status helps to keep a check on the path of the defect or bug and examines its progress in the defect or bug life cycle.
The various defect or bug statuses are listed below −
New
Potential defect that is raised and yet to be validated. This is the first status of a defect or a bug life cycle. Once a testing team begins its task, it identifies all the possible areas in the application under test where the actual and the expected results are not matching.
These are called as a defect or a bug and it is expected from the testing team to create a defect or a bug document having all the details like the steps to reproduce the defect or the bug, expected and actual results, environment, relevant screenshots, and so on. Along with that, all the relevant logs should be provided by the testing team. A well documented defect or a bug helps the defect to be fixed quickly.
Assigned
Assigned against a development team to address it but not yet resolved. Once a defect or a bug is in the new state, it is triaged in a meeting. Post discussion, if the new defect or the bug is proved to be a valid one, it is assigned to a developer. After assignment, the status of the defect or the bug is changed from New to Assigned.
Open
The Defect or the bug is being addressed by the developer and investigation is under progress and the developer fixes the error in the code which has caused the defect or the bug. At this stage, if the developer comes to the conclusion that the raised defect or the bug is not proper as per the current state of the project he can Defer or Reject the defect or the bug.
Fixed
Once the developer fixes the code and makes the necessary changes to remove the defect or the bug in the application under test, the defect or the bug status is changed to the fixed state. It also indicates that the code changes will be ready for testing from the upcoming build.
Test
The defect or the bug is fixed and ready for testing to verify if the defect or the bug exists in the application any more, and there is no deviation from the actual and expected results.
Verified
The Defect that is retested and the test has been verified by a tester. Post retesting the Defect or the bug, if the tester confirms if the defect or the bug no longer exists, and a right fix is provided by the developer, the Defect or the bug status is changed to verified.
Retest
The tester begins verifying the defect or the bug to confirm if it still exists or resolved in the application.
Closed
The final state of the defect that can be closed by the tester after he verifies that the defect or the bug no longer exists in the application.
Reopened
When the defect is NOT fixed, the tester reopens/reactivates the defect. Then the defect or the bug again moves to the Open state(journeys through the defect or bug life cycle again), for the developer to work upon.
Deferred
When a defect cannot be addressed in that particular cycle it is deferred to future release. If the defect or the bug identified by the tester is not on priority to be fixed, or there may be a requirement change from the customer and can be resolved in future releases or sprints, the status of the defect or the bug is changed to deferred.
Rejected
A defect can be rejected for any of the 3 reasons; viz - duplicate defect, NOT a Defect, Non Reproducible. A defect or a bug can be rejected by a developer because of improper communication or understanding from the tester.
Cannot Be Fixed
Once a defect or a bug is logged by the tester, and it is seen that the fix requires additional technology support, skills, and cost, at that time the status of the defect or the bug is changed to cannot be fixed.
Duplicate
It is seen that a defect or a bug is raised more than once, it is changed to the duplicate status. Ultimately, a duplicate defect or a bug is moved to the rejected status.
Not a Defect
If a defect or a bug logged is not impacting any requirements or functionalities of the application under test, it is moved to a not a defect status.
Not Reproducible
If a defect or a bug logged is not being replicated again because of not understanding the requirements, improper data, platform, build or the environment in which testing has been performed, the developer changes the status of that defect or the bug to not reproducible state.
Need More Information
If a defect or a bug logged is not being replicated again by the developer because of inadequate or improper details, evidence, and documentation provided by the tester, at that time the developer changes the statute of that defect or the bug to need more information. At that stage, it is the task of the tester to provide all the necessary information about the defect or the bug to the developer.
Defect Life Cycle - Workflow
The defect life cycle workflow is represented in the below diagram −
The steps involved in the defect or bug life cycle are listed below −
Step 1 − A member of the test team logs a defect or a bug which will have the status as New.
Step 2 − The defect or the bug is triaged and assigned to a developer for further analysis.
Step 3 − The developer goes through the defect or the bug and starts working on it. The defect or the bug status moves to the Open status.
Step 4 − If the defect or the bug is found to impact none of the functionalities or requirements(status known as Not a defect), or it is of less priority as of now and will be fixed in future release(status known as Deferred), or a duplicate one, the status of the defect or the bug is changed to the Rejected status.
Step 5 − If the Step 4 is not valid, the developer resolves the defect or the bug, the code changes start reflecting from the next build. The status of the defect or the bug is moved to Fixed.
Step 6 − The tester retests the defect or the bug and validates if it's resolved. If the defect or the bug no longer exists, the status of the defect or the bug is changed to Closed, else status of defect or the bug is changed to Reopened and again assigned back to the developer.
Conclusion
This concludes our comprehensive take on the tutorial on Software Testing - Bug Life Cycle. We’ve started with describing what is a defect or a bug, what is a defect or a bug life cycle, what is a defect or a bug status, and a defect or bug workflow.
This equips you with in-depth knowledge of the Bug Life Cycle in Software Testing . It is wise to keep practicing what you’ve learned and exploring others relevant to Software Testing to deepen your understanding and expand your horizons.
To Continue Learning Please Login