Defect Reporting and Tracking

Any mismatched functionality found in a application is called as Defect/Bug/Issue.

During Test Execution Test engineers are reporting mismatches as defects to developers through templates or using tools.

Defect Reporting Tools:
  • Clear Quest
  • DevTrack
  • Jira 
  • Quality Center
  • Bug Jilla etc.

DEFECT REPORT CONTENTS
  • Title/Summary:
    • A brief, descriptive title that summarizes the defect.
  • Issue Description:
    • A detailed description of the defect, including the steps to reproduce it.
    • Any relevant input data or conditions that trigger the defect.
  • Environment Details:
    • Information about the environment where the defect was observed (e.g., operating system, browser version, device).
  • Expected Behavior:
    • A clear explanation of what the expected behavior should be according to the specifications or requirements.
  • Actual Behavior:
    • A description of the actual behavior observed, which deviates from the expected behavior.
  • Severity/Priority:
    • An assessment of the impact and urgency of the defect.
    • Severity levels could include critical, major, minor, etc.
    • Priority levels could include high, medium, low, etc.
  • Attachments/Screenshots:
    • If applicable, attach screenshots, log files, or any other relevant files that can help in understanding and resolving the defect.
  • Date and Time of Discovery:
    • The date and time when the defect was initially discovered.
  • Steps to Reproduce:
    • Detailed steps or a test case that can be followed to reproduce the defect.
  • Test Data Used:
    • Information about the test data used when encountering the defect.
  • Assigned To:
    • The person or team responsible for addressing and fixing the defect.
  • Status:
    • The current status of the defect (e.g., open, in progress, resolved, closed).
  • Version/Build Number:
    • The version or build number of the software in which the defect was found.
  • Additional Comments/Notes:
    • Any additional comments, notes, or information that might be helpful in resolving the defect.
  • Tested By:
    • The name or identifier of the person who discovered and reported the defect.

Defects Categorization



Defect Severity

Severity describes the seriousness of defect and how much impact on Business workflow. 

Defect severity can be categorized into four classes.

Blocker(Show stopper): This defect indicates nothing can proceed further.
  • Ex: Application crashed, Login Not worked
Critical : The main/basic functionality is not working. Customer business workflow is broken. They cannot proceed further.
  • Ex1: Fund transfer is not working in net banking
  • Ex2: Ordering product in ecommerce application is not working.
Major: It cause some undesirable behavior, but the feature/application is still functional.
  • Ex1: After sending email there is no confirm message
  • Ex2: After booking cab there is no confirmation.
Minor: It won't cause any major break-down of the system
  • Ex: Look and feel issues, spellings, alignments.
Defect Priority
  • Priority describes the importance of defect.
  • Defect Priority states the order in which a defect should be fixed. 
Defect priority can be categorized into three classes:

P0 (High) : The defect must be resolved immediately as it affects the system severely and cannot be used until it is fixed.
P1 (Medium):  It can wait until a new versions/builds is created
P2 (Low): Developer can fix it in later releases.


Defect Resolution

After receiving the defect report from the testing team, development team conduct a review meeting to fix defects. Then they send a Resolution Type to the testing team for further communication.

Resolution Types:
  • Accept
  • Reject
  • Duplicate
  • Enhancement
  • Need more information
  • Not Reproducible
  • Fixed
  • As Designed

DEFECT LIFE CYCLE




The defect life cycle, also known as the bug life cycle, describes the stages that a defect goes through from the time it is identified to when it is successfully fixed and verified. The specific stages may vary depending on the software development process used by an organization, but the following is a general representation:

New/Open:
The defect is identified and reported.
It is in the initial stage, awaiting triage and assessment.

Assigned:
The defect is assigned to a developer or a development team.
A responsible individual or team is now accountable for investigating and fixing the defect.

In Progress:
The assigned developer or team actively works on fixing the defect.
Changes are made to the code or other components to address the reported issue.

Fixed/Resolved:
The developer believes they have fixed the defect.
The fix is implemented, and the code is submitted for review.

Verified/Closed:
The fixed code is reviewed and tested to ensure that the defect has been successfully addressed.
If the verification is successful, the defect is marked as closed.

Reopened:
If the defect is found to persist or if new issues arise after closure, it may be reopened.
The defect goes back into the "Assigned" or "In Progress" stage for further investigation and resolution.

Duplicate:
If it is determined that the reported defect is a duplicate of another already reported issue, the duplicate is closed, and the original defect is addressed.

Rejected :
In some cases, a reported issue might be deemed not to be a defect or not to require immediate attention.
The defect is marked as rejected and remains in the system for reference.

Deferred:
If the reported defect is deemed to be of lower priority and is not critical for the current release, it may be deferred to a later release.












Labels: , , , , , , ,

Followers