DEFECT LIFE CYCLE, also known as Bug Life Cycle, is the journey of a defect from its identification to its closure. The life cycle varies from organization to organization and is governed by the software testing process the organization or project follows and / or the Defect Tracking tool being used.

Statuses

During the life cycle of a defect, it can have the following statuses:

Elaboration

• OPEN / NEW: Defect is identified through a review or a test and reported. This is the beginning of a defect’s journey.
• ASSIGNED: The defect is assigned to a person who is tasked with its analysis or resolution.
• DUPLICATE: If the defect is invalid because it’s a duplicate of another one already reported, it is marked as a duplicate.
• DROPPED / REJECTED: If the defect is invalid because of various other reasons like false positives, it is dropped / rejected.
• DEFERRED: If the defect is valid but it’s decided to be fixed in a future release instead of the current release, it is deferred. When the time comes, the defect is assigned again.
• FIXED / RESOLVED / COMPLETED: After the defect is ‘fixed’, its status is changed so that its verification can begin. If the defect can’t be fixed, it could be because of any of the following reasons:
  • Need More Information: More information, such as the exact steps to reproduce, is required to analyze and fix the defect.
  • Can’t Reproduce: The defect cannot be reproduced for reasons such as change of environment, or the defect somehow being already fixed.
  • Can’t Fix: The defect cannot be fixed due to some other reason. Such defect is either assigned to another person (in the hope that the other person will be able to fix it), deferred (in the hope that the delay in fixing won’t hurt much), or dropped (when there’s no hope for its resolution ever and the defect needs to be considered as a ‘known issue’)
• REASSIGNED: If the ‘fixed’ defect is, in fact, verified as not being resolved at all or being only partially resolved, it is reassigned. If there’s time to fix the reassigned defect in the current release, it is fixed again but if it’s decided to wait and fix in a future release, it is deferred.
• CLOSED / VERIFIED: If the defect is verified as being resolved indeed, it is closed. This is the happy ending.

Grab the opportunity to learn Full Stack Development with Entri!

Guidelines

• Make sure the defect life cycle to be used in your project is well-documented and the entire team understands what each defect status exactly means.
• Ensure that each member of the team is clearly aware of his / her responsibility as regards each defect and its current status.
• Ensure that enough detail is entered in each status change. For example, do not simply drop a defect but provide a reasonable reason for doing so.
• Make sure the status of the defect in the defect tracking tool reflects the actual status. For example, do not ask for verification without changing the defect’s status to FIXED.

Introduction to Bug in Software Testing

Bug in software testing is flaw or default in a component or system or software that can cause the components or system to fail to perform its required functions, in other words, we can say that if the bug or defect encountered during the execution of the test, it may cause the failure of the components i.e. does not works as it expected from the components. For example, incorrect data definition, statements, input data, design, etc

Life Cycle of Bug in Software Testing

The Bug Life cycle is also known as a Defect Life cycle. It is a phase of a defect that occupies the different states during its lifetime. It starts when a testing device finds a new defect and ends when the testing device removes that defect, and it is ensured that the defect is not replicated. It is now time to understand, through a basic diagram as shown below, the true workflow of a defect life cycle.

Status of Bug

Let us see each component of the bug life cycle.

1. Open

The programmer begins the bugs analysis process and works to repair it. If the programmer thinks that the defect is not sufficient, then an error depending on the particular reason may be passed to the following four states, Reject or Not, namely Duplicate.

2. New

This is the first state of bug classification in the life cycle of the bugs. In the later stages of the bug life cycle validation and testing are carried out on these bugs if a new defect is discovered.

3. Assigned

The development team is allocated a newly created fault for operating on the fault at this level. This will be delegated to a designer by the project leader or the team’s boss.

4. Pending Retest

Upon fixing the defect, the designer will give the tester the fault for retesting the fault and the state of the defect stay in pending re-test until the tester works on re-testing the fault.

5. Fixed

If the developer completes the task of repairing a defect by making the necessary changes, the defect status can be called “Fixed.”

6. Verified

If the tester has no problem with the defect after the designer has been assigned the defect to the testing device and thought that if it was correctly repaired, the defect status is assigned “confirmed”.

7. Re-open

If there is still some problem with the flaw, the programmer will then be instructed to check again, and the defect status will be reopened.

8. Closed

If the defect is absent, the tester changes the defect status to ‘Closed’.

Grab the opportunity to learn Full Stack Development with Entri! Click Here

9. Retest

The tester then begins the task of re-testing the defect to check whether the defect is correctly fixed by the developer as required by the requirement.

10. Duplicate

If the developer considers the defect similar to any other defect, or if the defect definition blends into any other defect, the defect status is changed by the developer to ‘duplicate’.

Parameter of Bug in Software Testing

• Date of issue, approvals, author, and status.
• Severity and incident priority.
• The test case showed the problem.
• Incident definition with reproductive steps.

Guidance for Deficiency Life Cycle Implementation

• The entire team must understand clearly the different conditions of a bug before beginning the research on the defect life cycle.
• To prevent confusion in the future, the defect life cycle should be documented properly.
• Ensure that every person with any task related to the Default Life Cycle understands his / her responsibility for better results very clearly.
• Every individual who changes the status of a defect should know the status properly which should provide enough information about the status of a defect and the reason for it so that everybody who works on that defect can easily see the reason for the defect.
• The defect tracking tool should be handled with care in the workflow of the defect life cycle to ensure consistency between the defects.

Bug in Software Testing

Here, we will learn about defect/bug in software testing and why it occurs, basic terminology of a defect, and bug tracking tool.

What is a bug in software testing?

The Bug is the informal name of defects, which means that software or application is not working as per the requirement.

In software testing, a software bug can also be issue, error, fault, or failure. The bug occurred when developers made any mistake or error while developing the product.

While testing the application or executing the test cases, the test engineer may not get the expected result as per the requirement. And the bug had various names in different companies such as error, issues, problem, fault, and mistake, etc.

Basic terminology of defect

Let see the different terminology of defect:

• Defect
• Bug
• Error
• Issue
• Mistake
• Failure

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:

• Wrong coding
• Missing coding
• Extra coding

Wrong coding

Wrong coding means improper implementation.

For example: Suppose if we take the Gmail application where we click on the “Inbox” link, and it navigates to the “Draft” page, this is happening because of the wrong coding which is done by the developer, that’s why it is a bug.

grab the opportunity to learn web development with Entri

Missing coding

Missing coding means that the developer may not have developed the code only for that particular feature.

For example: if we take the above example and open the inbox link, we see that it is not there only, which means the feature is not developed only.

Extra coding

Here, extra coding means that the developers develop the extra features, which are not required according to the client’s requirements.

For example,

Suppose we have one application form wherein the Name field, the First name, and Last name textbox are needed to develop according to the client’s requirement.

But, the developers also develop the “Middle name” textbox, which is not needed according to the client’s requirements as we can see in the below image:

If we develop an extra feature that is not needed in the requirement, it leads to unnecessary extra effort. And it might also happen that adding up the extra feature affects the other elements too.

Bug tracking tool

We have various types of bug tracking tools available in software testing that helps us to track the bug, which is related to the software or the application.

Some of the most commonly used bug tracking tools are as follows:

• Jira
• Bugzilla
• Redmine
• Mantis
• Backlog

Jira

Jira is one of the most important bug tracking tools. Jira is an open-source tool that is used for bug tracking, project management, and issue tracking in manual testing.

Jira includes different features like reporting, recording, and workflow. In Jira, we can track all kinds of bugs and issues, which are related to the software and generated by the test engineer.

Bugzilla

Bugzilla is another important bug tracking tool, which is most widely used by many organizations to track the bugs.

Bugzilla is an open-source tool, which is used to help the customer, and the client to maintain the track of the bugs.

It is also used as a test management tool because, in this, we can easily link other test case management tools such as ALM, quality Centre, etc.

Bugzilla supports various operating systems such as Windows, Linux, and Mac.

Bugzilla has some features which help us to report the bug easily:

• A bug can be list in multiple formats
• Email notification controlled by user preferences.
• Advanced searching capabilities
• Excellent security
• Time tracking

Redmine

It is an open-source tool which is used to track the issues and web-based project management tool. Redmine tool is written in Ruby programing language and also compatible with multiple databases like MySQL, Microsoft SQL, and SQLite.

While using the Redmine tool, users can also manage the various project and related subprojects.

Some of the common characteristics of Redmine tools are as follows:

• Flexible role-based access control
• Time tracking functionality
• A flexible issue tracking system
• Feeds and email notification
• Multiple languages support (Albanian, Arabic, Dutch, English, Danish and so on)

MantisBT

MantisBT stands for Mantis Bug Tracker. It is a web-based bug tracking system, and it is also an open-source tool.

MantisBT is used to follow the software defects. It is executed in the PHP programing language.

Some of the common features of MantisBT are as follows:

• Full-text search
• Audit trails of changes made to issues
• Revision control system integration
• Revision control of text fields and notes
• Notifications
• Plug-ins
• Graphing of relationships between issues

Backlog

The backlog is widely used to manage the IT projects and track the bugs. It is mainly built for the development team for reporting the bugs with the complete details of the issues, comments. Updates and change of status. It is a project management software.

Features of backlog tool are as follows:

• Gantt and burn down charts
• It supports Git and SVN repositories
• IP access control
• Support Native iOS and Android apps

Conclusion

I hope you have got some knowledge of a defect’s life cycle.