What is bug life cycle in manual testing?

Errare humanum est. To err is human. But.. not only. Software gets mistaken, too. If you have come across any issues with the application or software that you are using, you know what we are talking about.

The software problem that you might or might not have encountered is commonly known as a bug or defect.

Bugs found during testing should be eliminated before the release of the software. Why? To ensure that customers get a good quality product their end. That is why a bug life cycle (also known as a defect life cycle) has been introduced.

[brakująca grafika]

The defect life cycle (also called the bug life cycle) is a process or a procedure during the software development phase that focuses on resolving the defect found during testing. Within the bug life cycle, the bug goes through different stages in its lifetime – from the stage when it is opened by the tester up to the status “closed” once it has been fixed.

There are two main team members who are involved in the process of the bug life cycle:

• Software Developer: designs and implements the code
• Software Tester: finds all the bugs in the software and opens them for fixing in the

The bug life cycle is an important and deciding part of the software development process. Why? Through resolving the bugs, the development team makes sure that the company receives the defect-free product.

By following the bug defect cycle, the company ensures that all the bugs are detected and resolved efficiently so that they do not corrupt or interrupt the production phase. Also, as the final product is bug-free, the company can maintain their business continuity as well as high level of quality when conducting their business operations.

To put it shortly, a system bug is any abnormal behavior of the system. Its lifetimes starts when the bug (also called the defect) is found and ends once the defect has been closed. This means that there is no way it is reproduced.

A bug is something that might arise in software for multiple reason. It may be some mistake made by software development team member – either during the design or development of the product that is tested. The tester or Quality Assurance team’s main responsibility is to find all the bugs found. A bug-free system means the software can be released. Otherwise, the go-live is put on hold.

PROS:

• You get to deliver a high-quality, healthy and dependable product
• The development costs decrease. Each process step is marked and well-documented. This means you need fewer resources for fixing the issues.
• Finding and fixing bugs promotes better cooperation between the development and the testing team.
• You get to detect issues early on – again, this lowers the costs.
• A bug life cycle, if properly done, enhance customer satisfaction and enables better service.

CONS:

• No single way to control the process A-Z: all issues are marked and tracked in real time.
• Some think that there are other lifecycle variations that allow for better tracking of the defects (and bug life cycle might be deemed obsolete)

The defect life cycle consists of several stages where the bug gets different status names. The status of the bugs can change multiple times, depending on the situation (testing results). The bug status (or the defect status) simply refers to the current stage of the defect in the bug life cycle.

The goal of each of the defect statuses is to convey information as to what is happening with the bug so that the whole team can understand and track each bug more effectively.

As the bug life cycle progresses, testers need to create a bug report which contains the information regarding the bug’s status and all other necessary data that would enable developers to understand what the issue is.

STAGES OF THE BUG LIFE CYCLE

The bug life cycle includes the following stages:

NEW: this is when a defect is logged and posted for the first time.

ASSIGNED: when the bug is posted by the tester, it then goes up to the lead tester to be approved. Then, the defect is assigned to the developer team. There are two possibilities here. Either the defect can be assigned to the developer who own the defect of the functionality or it get assigned to the Dev Lead who approves the defect and moves it further to the developer.

OPEN: this is the status when the developer starts analyzing the defect on working on how to fix it. The developer start analyzing the bug on the basis of the report created by the tester (in step 1). During this stage, the software developer works of fixing the code or rejects it if they consider this to be not a bug.

FIXED: the developer marks the bug status as FIXED once they have applied all the necessary code changes to it and verified them, too.

PENDING RETEST: this status is assigned to the bug between the time it gets FIXED by the developer and the time when the tester starts retesting to see if the problem has been resolved or still occurs.

RETEST: this status considers the fixed defects. Dev Lead moves all the defects in status FIXED to RETEST: once the latest build is pushed to production. This indicates to the testing team that the bugs are ready to be tested. At this stage, the tester retests the change code (handed over by developer) to see if it got fixed or not. The developer might recommend a fix that has implications for other sections of the code and that may require significant regression testing.

REOPENED: if in RETEST stage the bug still shows as not fixed, the tester changes the status to REOPENED. Then, the bugs goes through all the stages again (just the same as all defects with OPEN status).

DEFERRED: the defect with this status indicates a bug that is expected to be fixed in future releases. The reasons for assigning this status are multiple. It might be, for example, that the priority for fixing the bug is low or there is not enough time before the release or the bug is not critical for the software functionality.

REJECTED: if the developer considers the bug as not genuine, it gets rejected.

DUPLICATE: the bug is assigned this status if it is repeated twice or there are two bugs that mention the same concept of the defect. Out of the two bugs, the most recent one get the status DUPLICATE

CLOSED: once the defect gets fixed, it is tested by the tester. It might transpire that the big actually does no longer exist in the software. Then, the tester changes its status to CLOSED. This means the bug is fixed, tested and approved.

ENHANCEMENT/ NOT A BUG: This is the status if the defect is actually no defect. This means that it does not impact the functionality of the application in any way (e.g. changing the color of some text fields, etc.).

Finding the bugs is one thing. Reporting and tracking them is a different one. Writing a proper bugs report actually requires a lot of skill. If the developers are not able to reproduce the bugs found, it might be quite tough to fix these.

Reporting and tracking the bug also depend heavily on the tool that you use. It is best to use a professional tool that can record, report and monitor the bugs throughout the entire software testing process. Also, the debugging and bug tracking software should contain mandatory fields to ensure that the description of the defects that the testes encountered is accurate and full. A robust testing ecosystem is highly likely to improve the results of the bug-tracking lifecycle.

As for any unresolved bugs, they should be reviewed during the go-/no-go meetings by all the stakeholders. They collectively decide then if the application is ready for production or not. That means that although monitoring the bug life cycle is the responsibility of the support team (from registering a bug to fixing it), the stakeholders are the one who should make decisions as to how to proceed with bugs that have not been resolved in the build or release.