Practical Defect Life Cycle followed in IT companies

12 years back, as an aspiring QA, theoretically, I knew everything about a defect. What defect is? How it is different from an error? But what I didn’t know and used to wonder is, how testers communicate it to developers? How testers will know if it’s a valid defect? What if another QA has found the same defect? Basically I was unaware of how the defect/bug life cycle practically works in companies.

There are many blogs that conceptually explain software defects, but this article will help freshers like you to gain all practical knowledge regarding the defect, defect life cycle, it’s reporting, etc.  So let’s start…

What is Defect?

Developers can make mistakes while designing and creating software. These mistakes indicate that there are flaws in the software. So, after the development phase, it is the responsibility of a tester to do systematic testing of an application with an intention to find as many defects as possible, so the quality product will get delivered to the customer.

In simple words, when the expected results don’t match with the actual outcome, it is called a defect.

A Defect which is also referred to as BUG is an error in logic or coding which causes a program to produce wrong results.  It is something different than the customer requirement.

Difference Between Error, Defect, and Failure?

ERROR: it is also known as a mistake, means human-made mistake/misconception related to design or a variation from the actual business requirement. If the authorized person gathers requirements from the client wrongly, it is called Error.

DEFECT: it is also called as Bug or Fault. The error in coding is referred to as Defect/Fault/Bug. If the development team coded the incorrectly gathered requirement, it results in a Defect.

FAILURE: Failure means any difference from the desired result. The fault made in coding results in unexpected outcomes that are different from the client expectation. In that case, we say it’s a project ‘FAILURE.’ 

Some of the common types of defects that occur during development:

• Arithmetic Defects: while performing arithmetic calculation may get bug-like Arithmetic overflow or underflow.
• Logical Defects: Suppose you are getting unexpected output for a given input it indicates a Logical error. Ex. Use of the wrong formula for calculation, Infinite loops, etc.
• Syntax Defects: Syntactic bugs are nothing but the grammatical mistakes or misspelled words used in product GUI. One more ex. is the use of the incorrect operator etc.
• Multi-threading Defects:  Example of this type of defect is Deadlock, Process1 can’t start on till Process2 finished, Process2 cannot start on till Process1 finishes.
• Interface Defects:  Wrong Functions, Doesn’t perform as per the user expectations, Missing information and Confusing information, Wrong info in Help text, wrong error messages. Performance issues.
• Performance Defects: this defect indicates the performance issue of the code. For eg. more time taken to open the webpage.

Software Defects are basically classified according to :

• Severity
• Priority
• Related Module
• Phase Detected

Severity and Priority:

Severity and Priority are one of the attributes of a defect and the bug report should include these attributes to decide how quickly a bug should be fixed.

Defect Severity can be defined as the (how critical)impact of the bug on the application.

There are typically 4 types of Severity:  1. Minor   2.  Major   3. Medium    4.  Critical

Priority can be defined as the impact of the bug on the customers’ business. Priority provides the order in which a bug should be resolved.

There are typically 3 types of Priority:  1. High    2.Medium    3.Low

Higher priority bugs should be treated first. The main intention is how soon the defect should be fixed.  Most of the times the priority status is set based on the customer requirement

High severity, Low Priority defect: It means bug can create a major problem on the functionality of the system but only in rare conditions.

Example: On a flight operating website, there would be a defect in reservation functionality if the user uses an old browser for reservation of tickets.  This problem is severe but the number of customers with old browsers is very low. So it is not a high priority to fix the bug.

High Priority, Low Severity defect: It means the bug can’t create a major problem on the functionality of the system but needs to solve on high priority.

Example: Suppose a Logo on any particular website is wrong, so we can say this bug can be of low severity as it not going to affect the functionality of the system and very easy to fix but can be of high priority as it totally gives wrong information of a website. 

Logging defect in Defect Management Tool:

As soon as a tester finds a bug or defect, it needs to convey the defect to the developers. So it is conveyed by using Bug Reports, issue report, problem report, etc. And usually, it’s done by logging defect in Defect Management Tool e.g ALM QC

Below is the screenshot of ALM QC where we can log a defect

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This Defect report contains the following information:

• Defect ID – Defect’s a unique identification number and created automatically
• Summary – summary of a defect
• Detected By – Details of the tester who reported the defect like Name and ID
• Detected on Date – Date when the defect is logged
• Defect Description – details of the issue like steps to reproduce, expected o/p, actual o/p, DB details if necessary. Screenshots attached so that developers can recreate it.
• Project Team – resources who should get notification of defect
• Developer –Whom the defect is assigned
• Test Client – product version of the application in which the defect is found.
• Defect Status – this includes the Status of the defect like New, Assigned, Open, Retest, Verification, etc.
• Date Closed – Date when the bug is closed
• Severity – Based on the severity it tells us about the impact of the defect or bug in the software application
• Priority – Based on the Priority set, it can be High/Medium/Low, the order of fixing the defect can be made.

These above fields can vary somewhat depending upon the project or tool that is used.

All the defects logged can be exported in an excel sheet and that is shared as a defect report with the team. Here is the sample defect status report.

4 Steps To Draft Effective Defect Report – Sample Defect Status Report in Excel to download

Defect Life Cycle?

This term is only used in an interview but thoroughly understood not only by QA but each and everyone in the team.

A Defect Life Cycle or Bug life cycle is a cycle in which a defect goes through during its life span. It starts when a defect is found by the tester and ends when a defect is closed by the tester, after ensuring it’s not reproduced.  In short, we can say that its a time span of a defect from its identification to its closure.

There are no fixed states given in the Defect life cycle it varies from organization to organization, from project to project and depends on which tool being used. But below is a quiet common flow of a defect.

Defect Life Cycle includes the following stages:

1. New:  When any new defect is logged in QC or any tool, it’s status is given as new.
2. Assigned: Once the defect is logged by the tester, the test lead or developer approves that the bug is valid then it will get assigned to the developer team. It’s a state marked as assigned.
3. Open: in this stage, the developer starts the process of analyzing the defect and if required he works to fix it. If the developer feels that the defect is not suitable then it may get transferred to any of these four states by considering a particular reason.
   1. Duplicate: If the developer finds the defect same as any other defect or if the idea of the defect matches with any other defect then the status of the defect is marked as a ‘Duplicate’ by the developer.
   2. Deferred: If the developer feels that the defect is not on priority and it can get fixed in the next releases, in such a case, the status of the defect is marked as ‘Deferred’.
   3. Rejected:  If the defect is not considered as an authentic defect by the developer then it is marked as ‘Rejected’.
   4. Not a Bug: If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to ‘Not a Bug’.
4. Fixed: Now the developer makes necessary changes in the code and verifies the changes then the bug status marked as ‘Fixed’ and the bug is assigned to the testing team.
5. Pending retest:  After a fixed state, the developer will give that particular code to the tester for retesting. Now the testing is pending on the tester’s side. Hence the status is pending retest. (Many companies omit this state)
6. Retest:  In the Retest stage, the tester does retesting of the changed code which was given by the developer to him to check whether the defect got fixed or not.
7. Verified: The tester tests the defect again after it got fixed by the developer. If the bug is cleared or it is not present in the software, then he approves that the bug is fixed and changes the status to “verified”.
8. Reopen: After the defect is fixed by the developer, if the bug still is present, the tester changes the status to “reopened”. Then the bug goes through the life cycle once again.
9. Closed: As the defect gets fixed, it is tested by the tester. If the tester feels that the bug no longer presents in the software, then he will change the status to “closed”. This state means that the defect is fixed, tested, and approved.

Conclusion:

For each state of the defect, the mail is sent by defect management tool to the developer, tester, and whoever is tagged in the defect while logging it. As a respected owner needs to take action on it.

That’s all about Defect or Bug life cycle, this article covered enough information about the Defect and the number of steps in the Defect life cycle.

Please feel free to ask questions or share your comments.