The bug life cycle is also commonly known as the defect life cycle. In this article we will look into the definition of bug and describe the bug life cycle in detail. For ease of use and consistency, we will use the term ‘bug’ instead of ‘defect’, because although both terms are in use today, the more common is ‘bug.’
What is a Bug?
We have all come across bugs, most probably in a range of computer systems. In short, a bug is defined as a failure in a program’s design or source code, usually as result of human error or omission, that prevents the computer programme or software from delivering the correct result. This can mean anything from a page not loading, being mis-directed or the wrong items or amounts being placed in an e-commerce shopping cart.
In other words, it can be said that deviation of any function from expected output results in a bug or defect. Bugs may arise in the software application at any stage of the Software Development Life Cycle (SDLC), whether it is during the requirement gathering phase or in other phases such as design, coding and most importantly, the testing phase. It may also occur while the software application is actually being used by the end user. Hence, there is no guarantee of avoiding a bug or bugs. Before moving on, it is very important to understand that if any bug is missed during the testing phase, there is a high chance that it will appear in the production environment and cause serious repercussions, which could include monetary losses, depending on the severity of the bug.
Though this article’s emphasis will be on the bug life cycle, the above introduction is important to help understand the basic principle. In the next section we will discuss the bug life cycle.
Stages In A Bug Life Cycle
Defect Identification: In order to identify a defect, the tester will have to be aware of the expected result in the system’s functionality. During the execution of test cases, the tester compares the result of actual output with the expected output, and if results vary or do not match, then it is considered as bug that needs to be fixed. While reporting the bug to development team, the tester should provide a proper report containing the actual and expected output. New, assigned and reopened statuses fall under this category and it should be moved to a resolved status after that.
Resolving Bug: Developer(s) should rectify the bug but without producing any serious repercussions. Following the fix, the behavior of the system’s functionality should work as expected and the bug removed. The statuses of fixed, duplicated, cannot reproduce, not a defect, and cannot resolve, lie within this category. From this stage onward, the bug is ready to retest.
Bug Retesting: After being fixed by the developer, the tester needs to retest the particular bug in their test environment. They will check whether the bug is fixed and that the system’s functionality is working as expected or not. Those bugs which are in the fixed, duplicated, cannot reproduce, not a defect and cannot resolve, statuses are verified at this stage. When the tester has completed re-testing, the bug is either given the status of reopened if the problem has not been resolved, or closed if it has been fixed and verified.
Bug Status Explained
New: Whenever a software application encounters a bug, a tester is supposed to raise a notification of the bug. Initially, the bug is in the ‘New’ state of the life cycle. A tester should always re-test and analyze the bug to establish its validity.
Assigned: When the bug is raised, a tester will directly assign it to the developer to fix the bug. The tester should be aware of the developer to whom the bug is assigned. Once the bug is assigned, it is now developer’s turn to resolve the issue.
Fixed: Before fixing, a developer will check the bug and analyze it. If the bug is reproducible and fixable, a developer will fix it, making sure that fixing will not have a negative impact on other areas of the software application.
Deferred: There may be a situation where a bug is valid but it is more convenient to work on it at a later date with future releases. Transferring a bug to be fixed with future releases is known as the deferred state.
Duplicate: This situation can appear when another team member(s) or tester has already reported the same issue as now being reported. In this case, the bug may be valid but the developer will mark this as duplicate.
Not a Defect: If a bug is not valid, then it is marked as ‘Not a Defect’ by developer.
Cannot Reproduce: There might be some cases when the developer is not able to reproduce the same bug as reported by the tester. In this case, the developer marks this bug as cannot reproduce or unable to reproduce. It is highly recommended that the tester re-tests the bug before logging the issue. Some bugs are environment specific, so they may appear on some machines which are running the application but not appear on other machines. For this reason, it is good to collaborate with the tester to find the root cause and resolve the bug.
Cannot Resolve: There are instances when developers are unable to resolve the issue so they move them into the cannot resolve state. This might be due to technical limitations, or other reasons. When this state arises, wider discussions are needed with the team, and if necessary, to discuss the issue with the client.
Reopen: After the bug is passed through all of the above mentioned states and returns into the hands of testers for verification, a tester re-tests the bug to see whether it has truly been fixed. If the bug has not been resolved but appears again, it is then transferred to the reopen state so that the developer can rectify the issue.
Closed: If the bug is fixed and a tester verifies it, then the bug is moved to a closed state. Testers should also verify that the bug which is fixed should not appear again in the future. Depending on the severity of the bug, it will probably have to follow the same life cycle again.
Conclusion
Bugs are identified by testers in most of the cases then are resolved by the developer in every case. I have mentioned almost all of the stages of defect life cycle, as well as the states of the bug life cycle. It is important to make sure that the bug does not harm the other parts of the system and should be resolved in a smooth way. It is important to make sure that the bug will not appear again in the software application and the tester should maintain a bug report according to their respective organization/company practices, to analyze the application.
