What is a Defect

A Defect in Software Testing is a deviation of the Software Application under Test from the original business requirements OR end user’s requirements.

It is basically an error in coding which causes unexpected results from a Software Program which does not meet actual requirements.

A Software Test Engineer might come across such defects while executing the Test Cases.

What is a Defect Document/Bug Report

It is a detailed document about the Defects found in the Software Application.

A Defect Document contains each detail about the bugs like Issue, Description, Date when the defect was found, QA who raised it, Developer who will fix it etc.

We should include the below information while creating a Defect Document/Bug Report –

• Defect_id: It is a unique identification number for the Defect.
• Description: Detailed description of the Defect
• Expected Result: It talks about the expected behaviour of the Application.
• Actual Result: It talks about the Actual behaviour of the Application.
• Steps to Reproduce the Defect: How a Developer can reproduce the Defect in the local environment.
• Date raised: Date when the defect was raised.
• Reference: It includes the screenshots of the error, Business Requirement etc.
• Detected By: Name/User ID of the QA who raised the Defect.
  Status: Status of the Defect
• Fixed By: Name/User ID of the Developer who will fix the Defect.
• Date Closed: Date when the Defect is closed.
• Severity: It talks about the impact of the Defect on the Application. 
• Priority: It talks the urgency to fix the Defect.

A Sample Bug Report Template

DefectReportTemplate

What is a Defect Life Cycle

Defect Life Cycle or Bug Life Cycle in Software Testing is a specific set of states that a Defect or Bug goes through in its entire life. It helps in making Defect fixing process systematic and effective.

Defect Status or Bug Status in Defect Life Cycle is the present state from which the Defect or Bug is undergoing currently.

It helps in the understanding the actual progress of the Defect Life Cycle.

The number of states that a Defect goes through varies from Project to project, below are all possible states –

• New: When a new Defect is raised and assigned for the first time, it is assigned a status as ‘New’.
• Assigned: Once a QA posted a bug, the Lead of the QA Team approves the bug and assigns it to the Development Team.
• Open: The developer analyses the bug and starts working on the Defect fix.
• Fixed: When the Developer makes the necessary code change, also verifies the change; they can make the bug status as ‘Fixed’.
• Pending Retest: After the bug fix, the Developer assigns it back to the respective QA for retest. Since the Software Testing remains pending from the QA, the status remains as 'Pending Retest'.
• Retest: The QA does the retesting of the code and checks if the issue is fixed by the Developer or not.
• Verified: After retesting, if there is no bug detected in the code then the bug is fixed, and the status is changed to ‘Verified’.
• Reopen: If the issue persists even after the fix, then the QA changes bug status to ‘Reopen’.
• Closed: If the issue no longer exists then the QA marks it as ‘Closed’.
• Duplicate: If the issue is already reported earlier in another bug, then it is marked as ‘Duplicate’.
• Rejected: if the Developer feels that it is not a genuine issue then it is marked as ‘Rejected’.
• Deferred: If the bug is not of a prime priority and is expected to get fixed in the next release, the status is marked as ‘Deferred’.
• Not a bug: If the issue raised does not affect the functionality of the application, then it is assigned as ‘Not a bug’.