Practical Defect/Bug 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 its a valid defect? What if another QA has found the same defect? Basically I was unaware how defect/bug life cycle practically work in companies.

There are many blogs which conceptually explain software defects, but this article will help freshers like you to gain all practical knowledge regarding defect, defect life cycle, its reporting etc.  So lets starts…

What is Defect?

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

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

A Defect which is also referred 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.

What is the difference between Error, Defect and Failure?

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

DEFECT: it is also called as Bug or Fault. The error in coding is referred 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 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 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 ex. more time taken to open 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 typical 4 types of Severity:  1. Minor   2.  Major   4. Medium  .  Critical

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

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

Higher priority bugs should be treated first. 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: In a flight operating website, there would be a defect in reservation functionality if user uses old browser for reservation of tickets.  This problem is severe but number of customers with old browsers is very low. So it is not 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 give 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 its done by logging defect in Defect Management Tool e.g ALM QC

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

ALM QC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This Defect report contains following information:

  • Defect ID – Defect’s 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 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 excel sheet and that is shared as a defect report with team. Here is the sample defect status report.

Tips to draft Effective Defect Status 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 which a defect goes through during its life span. It starts when 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 fix states given in 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

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 develper approves that the bug is valid then it will get assigned to the developer team. It’s 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 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 a 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 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 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 Retest stage the tester do the retesting of the changed code which was given by 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 defect is fixed by the developer, if the bug still be present, the tester changes the status to “reopened”. Then the bug goes through the life cycle once again.
  9. Closed: As the defect get 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.

For each state of the defect, mail is sent by defect management tool to the developer, tester and whoever is tagged in the defect while logging 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 question or share your comments.

 

Add a Comment

Your email address will not be published. Required fields are marked *