One of our counsellors will get in touch with you soon!
One of our counsellors will get in touch with you soon!
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:
You may also like: Introduction to Quality Control And Quality Assurance
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.
It is important to understand the defect life cycle before moving to the workflow and different states of the defect.
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.
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.
You may also like: Business Development - Going with Your Gut Is Not Enough
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.
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.
Some best practices can be adopted before starting to work on the Defect Life Cycle.
You may also like: Zero Defects In Quality Management
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.
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.