Importance of Bug Life Cycle in Software Testing

Importance of Bug Life Cycle in Software Testing


Mistakes lead to the introduction of defects (also called bugs).  like all human beings I can make mistakes at any point in time, no matter what I might be working on. So it is on projects, where the business analyst can put a defect into a requirements specification, a tester can put a defect into a test case, a programmer can put a defect into the code, a technical writer can put a defect into the user guide, and so forth. Any work product can and often will have defects because any worker can and will make mistakes! Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.Below find the various states that a defects goes through in its life-cycle. The number of states that a defect goes through varies from project to project. Below life-cycle, covers all possible states.



  1. New: When a defect is logged and posted for the first time. It is assigned a status NEW.
  2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as Assigned.
  3. Open:  At  this state the developer has started analyzing and working on the defect fix.
  4. Fixed:  When developer makes necessary code changes and verifies the changes then he can make bug status as ‘Fixed’ and the bug is passed to testing team. 
  5. Retest:  At this stage the tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and change the status to “Re-test.”
  6. Verified/Resolved:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified/Resolved”.
  7. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
  8. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
  9. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate”
  10. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.If the developer feels the defect is not a genuine defect 
  11. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
  12. Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
  13. Known bug:These are problems known to exist at the time of this (Current)release.It is same as Deferred status.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal.The challenges of following a bug life cycle are far outweighed by the benefits derived. A well planned and closely managed defect database not only tracks current defects against any number of builds and/or products, it also provides a virtual paper trail for the overall progress of a product as it is coded, tested, and released. If sufficient time is provided for building a defect tracker that works for your company, it is more likely you will release a less buggy product, or at least a product where most of the big ones have not gotten away

STLC (Software Test Life Cycle)

STLC (Software Test Life Cycle)

Life-cycle in simple term refers to the sequence of changes from one form to other form. These changes can happen to any tangible or intangible things. Every entity has a life-cycle from its inception to retire / demise.In a similar fashion, Software is also an entity. Just like developing software involves a sequences of steps, testing also has steps which should be executed in a definite sequence.This phenomenon of executing the testing activities in a systematic and planned way is called testing life cycle.

The process of testing a software in a well planned and systematic way is known as software testing life cycle(STLC).Different organizations have different phases in STLC however generic Software Test Life Cycle (STLC) for waterfall development model consists of the following phases.

1. Requirements Analysis
2. Test Planning
3. Test Scenarios and Test Cases Development
4. Test Environment Setup
5. Test Execution and Bug Reporting
6.Test Cycle Closure

STLC Phases

1.Requirements Analysis

In this phase testers analyze the customer requirements and work with developers during the design phase to see which requirements are testable and how they are going to test those requirements.It is very important to start testing activities from the requirements phase itself because the cost of fixing defect is very less if it is found in requirements phase rather than in future phases.

2.Test Planning

In this phase all the planning about testing is done like what needs to be tested, how the testing will be done, test strategy to be followed, what will be the test environment, what test methodologies will be followed, hardware and software availability, resources, risks etc. A high level test plan document is created which includes all the planning inputs mentioned above and circulated to the stakeholders.

3. Test Scenarios and Test Cases Development

The test scenarios and test cases development activity is started once the test planning activity is finished.This is the phase of STLC where testing team write down the detailed test scenarios and test cases. Along with these, testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead. Also the Requirement Trace-ability Matrix (RTM) is prepared. The Requirement Trace-ability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward trace-ability.

4. Test Environment Setup

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Mean while testing team should prepare the smoke test cases to check the readiness of the test environment setup.

5. Test Execution and Bug Reporting

Once the unit testing is done by the developers and test team gets the test build, The test cases are executed and defects are reported in bug tracking tool, after the test execution is complete and all the defects are reported. Test execution reports are created and circulated to project stakeholders.
After developers fix the bugs raised by testers they give another build with fixes to testers, testers do re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of software.Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect fix.After tester assures that defects have been fixed and no more critical defects remain in software the build is given for final testing.

6.Test Cycle Closure

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.