All Courses
Login / Sign up
Get started

By signing up, you agree to our Terms of Use and Privacy Policy.
Reset your password
Enter your email and we'll send you instructions on how to reset your password.

Better software development and testing with the Defect Bug Life cycle

Better software development and testing with the Defect Bug Life cycle

Introduction

In this article, we will go through the life cycle of a defect. It will make you aware of the various stages of a defect.  Any tester must deal with these while working in a testing environment.

It is important to know about the various states of a defect. This will help understand the defect life cycle. The main reason for performing a testing activity is to check whether the product has issues or errors in them. 

During testing, we need to keep three groups in mind: 

  • Customer
  • Developer
  • Tester

What is a defect?

A defect is non-conformance to requirements. It is an error or a bug, in the application which is created. A Defect, in simple terms, is a flaw or an error in an application. It restricts the normal flow of an application. There is a mismatch in the expected behavior of an application with the actual one.

A defect refers to an error that occurs because of the mistake made by the developer during the designing of the application. Such errors are termed as defects by the testers. Mistakes can happen during requirement gathering, coding, or while making test cases.  While making test cases the expected behavior may not be stated clearly. These can be caught in different rounds of testing. Usually, we have at least two rounds of testing. After this, there will be User acceptance testing and go-live.

A tester is responsible for the thorough testing of an application. It is the responsibility of a tester to do thorough testing of an application. Testers need to find as many defects as possible to ensure that a quality product will reach the customer. Test cases should cover all possible scenarios. Inputs, outputs, and expected behavior should be clearly defined. 

Bug vs Defect vs Failure: Testing is the process of identifying defects. The defect is any variance between actual and expected results. "Error" is a mistake in code. Error found by the tester is termed as a defect. The defect accepted by the development team is called Bug. A defect found by a customer is a failure.

Different states of the defect

It is important to understand the defect life cycle before moving to the workflow and different states of the defect.

What is the defect bug life cycle?

In simple words, a defect life cycle is something that starts when a bug is detected and completes when it is closed. It is also known as a Bug life cycle. It is a cycle of a defect from which it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it will not get reproduced again.

It is now time to understand the actual workflow of a Defect Life Cycle with the help of a simple diagram as shown below.

Actual Workflow of a Defect Life Cycle

Classification of defects:

The classification of defects is based on the state the defect is in. The priority of a defect is mentioned as "High", "Medium" or "Low". Some organizations also have an impact of defects on a scale of 1 to 10. One being low impact and ten being high impact. The impact is rarely practiced in practical scenarios and may be factored in the priority. 

Defect States

  • New: "New" is the first state of a defect in the Defect Life Cycle. When any new defect is found, it falls into a “New” state. It then undergoes validations and testing in the later stages of the Defect Life Cycle.
  • Assigned: In this stage, a newly created defect is assigned to someone responsible for removing this defect.  Generally, it would be the development team for working on the defect. This is assigned by the project lead or the project manager of the testing team to a developer.
  • Open: Here, the developer starts analyzing the defect. If it is really a defect, then he works on fixing it. At times, the developer may feel that the defect is not appropriate. He then puts it to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon the specific reason. We shall discuss these four states in a while.
  • Fixed: The developer makes the required changes and finishes the task of fixing a defect. It goes to the “Pending Retest” status. It is re-tested by the tester and checked to ensure it does not re-occur. Once done, he will mark the status of the defect as ‘Fixed’.
  • Pending Retest: After fixing the defect, the developer assigns the defect to the tester for retesting the defect. Until the tester works on retesting the defect, the state of the defect remains as “Pending Retest”.
  • Reopen: If the issue persists or can be reproduced again, and the defect is not fixed then it is put in status “Reopen”. It will be assigned to the developer again with testing results. The developer then must work on fixing it.
  • Verified: This status tells that the defect has been fixed accurately. The tester did not find any issue in the defect after the developer fixed it. The tester would then set the status of the defect as ‘Verified’.
  • Closed: When the defect does not exist any longer, it is put in the status “Closed” by the tester. This is the final stage.

Few More:

Rejected: At times, the requirement may be fulfilled. There may be some gaps in understanding by the tester. Test script may not have captured expected behavior appropriately. Developers may not consider it a defect. He would provide reasons and mark the status as ‘Rejected’.

Duplicate: Duplicate means another defect already exists addressing the same issue. The developer may find another defect which is the same as the reported defect. The concept of the defect may match another defect. In such cases, the developer would change the status to ‘Duplicate’.

Deferred: Sometimes, it may not be possible to fix a defect due to some reason or dependency. At times, the defect may not be important and can be fixed in the next phase or release. In such cases, the developer would change the status of the defect to "Deferred"

Not a Bug: This indicates that there is no impact on the functionality of the application. The developer then changes the status of the defect to ‘Not a Bug’.

Now with this background let us dive into the defect bug life cycle. There are some mandatory fields a tester enters when logging a new bug. These are Build version, Submit On, Product, Module, Severity, Synopsis, and Description to Reproduce. In the above list, one can add some optional fields. These Optional Fields include Customer name, Browser, Operating system, File Attachments, or screenshots.

Look at the following Defect cycle:

Significant Steps in Bug Life Cycle

The above diagram is quite detailed. It considers the significant steps in the Bug Life Cycle. You will get a quick snapshot.

Once logged, the bug is reviewed by the concerned person. Usually Development or Test manager. After setting the bug status as open, the test manager can assign the bug to the developer or defer it until the next release.

When a bug gets assigned to a developer, he/she will review it. He can start working on it. He can change the bug status as ‘Will not Fix’,’ Could not Reproduce’, ‘Need more information’, or ‘Fixed'.

QA responds with a specific action when the bug status is set to either ‘Need more info’ or Fixed. Once the bug is fixed, then QA verifies the bug.  He then sets the bug status as verified closed or Reopens.

Best Practices for Implementing Defect Life Cycle

Some best practices can be adopted before starting to work on the Defect Life Cycle.

  • It is critical that before starting to work on the Defect Life Cycle, the whole team understands the different states of a defect.
  • Defect Life Cycle should be properly documented to avoid any confusion in the future.  Ensure everyone who has been assigned any task related to the Defect Life Cycle, should understand his/her responsibility clearly. This will ensure good results.
  • Everyone who is changing the status of a defect should be properly aware of that status. They should provide enough details about their status. Detailed reasons should be put for that status. This will help everyone who is working on that particular defect. They will understand the reason for such a status of a defect very easily.
  • The defect tracking tool should be handled properly.  It should maintain consistency among the defects

Future Scope of work:

Software is evolving and is becoming more flexible. With IoT, more devices are getting added to existing software. This has multiplied the testing requirements exponentially. With Artificial Intelligence and Big Data integration, there are infinite possibilities. So, testing and defect life cycle scope is ever increasing. Automation will take care of some part of it but there is a great need for subject matter experts. This is ever-increasing. Since, as we deep dive into certain applications or industries we need more insights of functionality to be covered, tested and bugs detected. With front end applications, the way users handle the application is changing drastically.  We have inputs provided by gestures, scanners, fingerprints, sensors, etc. So, the scope of testing and handling bugs is ever increasing. This would continue to increase. Old techniques will get automated. New methods will initially be handled manually until volumes indicate automation will help. There is scope in making those automation tools too, which again are ever-evolving.

Conclusion

Every business may have different requirements for defects. It is important to understand the states of defects. Clear documentation and creating awareness of correct usage is essential for effective utilization. Software and functionality being more dynamic than ever have increased the scope of this exponentially. Hope you have gained immense knowledge about the life cycle of a defect. This should help you work on defects in the future in a better manner.

Become a certified Quality Management Professional.

Recommended Courses

Dates: September 28,29,30 October 01 2020
Timings: 10:00 AM - 06:00 PM ET
USD 1100
USD 1500
Guaranteed to Run
Enroll
Dates: October 10,11,17,18 2020
Timings: 10:00 AM - 06:00 PM ET
USD 800
USD 1200
Guaranteed to Run
Enroll
Dates: October 10,11,17,18,24,25,31 November 01 2020
Timings: 10:00 AM - 06:00 PM ET
USD 1600
USD 2100
Dates: October 13,14,15,16 2020
Timings: 10:00 AM - 06:00 PM ET
USD 800
USD 1200
Guaranteed to Run
Enroll
Dates: October 13,14,15,16,27,28,29,30 2020
Timings: 10:00 AM - 06:00 PM ET
USD 1600
USD 2100

About The Author

Darshan Danda is a PMP & ITIL Certified Delivery Manager / Program Manager / Project Manager. He is enthusiastic & audience-focused content specialist, having 16+ years of IT experience. He also has a high focus on customers, employee, and organization. Darshan is always open to embrace innovative methods & ideas.

Darshan Danda

0 Comments

Add Comment

Subject to Moderate