Any member of the development team can make an error in any phase of SDLC. If an error has been produced in the requirement specification phase and not detected in the same phase, it results in a bug in the next phase, that is, the design phase. In the design phase, a bug comes from the previous stage, but an error can also be produced in this stage. Again, if the error in this phase is not detected and it passes on to the next stage, that is, coding phase, then it becomes a bug. In this way, errors and bugs appear and travel through various stages of SDLC, 'as shown in Fig: 1. It means that a stage may contain errors as well as bugs and the bugs, which come from the previous stage are harder to detect and debug.

In the testing phase, we analyze the incidents when the failure occurs. On the basis of symptoms derived from the incidents, a bug can be classified into certain categories. After this, the bug can be isolated in the corresponding phase of SDLC and resolved by finding its exact location.

The whole life cycle of a bug can be classified into two phases: (i) bugs-in phase and (ii) bugs-out phase.

Bugs-in Phase

This phase is where the errors and bugs are introduced in the software. Whenever we commit a mistake, it creates errors on a specific location of the software and, consequently, when this error goes unnoticed, it causes some conditions to fail, leading to a bug in the software. This bug is carried out to the subsequent phases of SDLC, if not detected. Thus, a phase may have its own errors as well as bugs received from the previous phase. If you are not performing verification on earlier phases, then there is no chance of detecting these bugs.

Bugs-out Phase

If failures occur while testing a software product, we come to the conclusion that it is affected by bugs. However, there are situations when bugs are present, even though we don't observe any failures. That is another issue of discussion. In this phase, when we observe failures, the following activities are performed to get rid of the bugs.

Bug classification

In this part, we observe the failure and classify the bugs according to their nature. A bug can be critical or catastrophic in nature or it may have no adverse effect on the output behavior of the software. In this way, we classify all the failures. This is necessary because there may be many bugs to be resolved, but a tester may not have sufficient time. Thus, categorization of bugs may help by handling high criticality bugs first and considering other trivial bugs on the list later, if time permits.

Bug Isolation

Bug isolation is the activity by which we locate the module in which the bug appears. Incidents observed in failures help in this activity. We observe the symptoms and back-trace the design of the software and reach the module/files and the condition inside it, which has caused the bug. This is known as bug isolation.

Bug Resolution

Once we have isolated the bug, we back-trace the design to pinpoint the location of the error. In this way, a bug is resolved when we have found the exact location of its occurrence.