Skip to main content

Defect Management Process

Purpose of defect management process​

The defect management process aims to establish a clear, robust framework for identifying, tracking, and resolving defects efficiently. Key goals include ensuring accountability, maintaining quality control, providing traceability, and facilitating data-driven improvements in development and testing processes.

This document will discuss the defect management process, adapting it for different types of projects.

For example:

  • Heavy Projects: Large, complex projects that require strict workflows, detailed documentation, and rigorous defect management processes.
  • Light Projects: Small-scale projects where flexibility and simplicity are prioritized, and strict documentation or processes are not essential.

Defect Management Tools​

Defect management tools help track, manage, and resolve defects efficiently, promoting collaboration and accountability.

  • Heavy Projects: JIRA and Azure DevOps are best for heavy projects needing detailed workflows, reporting, and CI/CD integration but can be simplified for lighter projects with future scaling in mind.
  • Light Projects: For smaller, less complex projects, tools should be simple, easy to use, and quick to set up. Here are some good options: Trello, Asana, Monday.com etc.

Control Measures​

To maintain the quality of the defect management process, several control measures are in place. These measures use role-based access and permissions to make sure that only authorized users can perform certain actions in the system. The controls are applied differently for Heavy Projects and Light Projects.

  • Heavy Projects: require more detailed workflows, strict access control, and formal approval processes for defect resolution.
  • Light Projects: have simplified controls and workflows, focusing on efficiency while maintaining key integrity measures for defect management.

Defect Triage Process​

The Defect Triage Process is a structured method for reviewing, prioritizing, and assigning defects found during testing. It ensures defects are managed systematically and resolved efficiently, helping the project stay on track. The process is crucial for managing defect backlogs, addressing critical issues first, and ensuring resources are allocated effectively.

Key Steps in the Defect Triage Process

  1. Initial Review

The first step in the defect triage process is to validate and assess the defect. This step confirms whether the defect is legitimate, reproducible, and has been reported correctly.

  • Goal: To ensure only genuine issues move forward in the process.
  • Action: The defect is reviewed by the test lead, developer, or expert to verify if it's caused by an actual fault or if it's due to a misunderstanding (e.g., user error, wrong test case, etc.).
  1. Categorization

Once a defect is confirmed as valid, it is categorized based on severity, impact, and priority.

  • Goal: To understand the potential impact of the defect on the project and the system.
  • Action: The defect is classified into categories such as:
    • Severity (e.g., blocker, critical, major, minor)
    • Priority (e.g., high, medium, low)
    • Type (e.g., functional, UI, performance)
  1. Triage Meeting

This is a collaborative meeting where the stakeholders (test leads, developers, product owners, etc.) gather to discuss the defect, its impact, and the resolution path. During triage meetings, updates are often added directly in the comments of the ongoing discussions. This helps ensure that the latest context and decisions are documented in real time, making it easier to track and reference later.

  • Goal: To prioritize defects and decide the appropriate actions and timelines for their resolution.
  • Action: The following key points are discussed:
    • Status Updates: Progress on defects raised in earlier testing phases.
    • Prioritization: Determine which defects need to be fixed first based on business needs, severity, and project deadlines.
    • Assignment: Assign the defects to the appropriate teams for investigation, resolution, or verification.
    • Root Cause Analysis: Identify recurring patterns in defects (e.g., poor coding practices, unclear requirements).

Defect triage process differs slightly for Heavy Projects and Light Projects.

  • Heavy Projects: both the Initial Review and Triage Meeting are formal processes involving multiple participants (Test Lead, Experts/Development Lead, Business Analyst, Project Manager) to ensure defects are thoroughly reviewed, prioritized, and addressed.
  • Light Projects: the Initial Review and Triage Meeting are more streamlined, involving only key roles like the Test Lead, Development Lead, and Business Analyst/Product Owner, with fewer formalities and quicker decision-making.

Environment Priorities​

The environment priorities (in terms of testing, development, and deployment) differ in various projects based on their complexity, scale, resource requirements and the goals of the project.

  • Heavy Projects: the environment structure prioritizes stability and scalability. Multiple isolated environments, like development, testing, staging, and production, ensure that each phase is thoroughly tested before deployment. Automation through CI/CD pipelines supports continuous testing and deployment. Performance and load testing are critical, as is maintaining a high level of security and compliance across all environments to meet industry standards.
  • Light Projects: the environment structure is simpler and more cost-effective, typically with just development and production environments. These environments are flexible, allowing for rapid development and testing cycles. There is less emphasis on complex performance or security testing, but basic security measures are still in place. The focus is on speed, agility, and efficient resource use.

Response and Resolution times​

Response and resolution times are key metrics in the defect management process, helping ensure that defects are addressed promptly and efficiently. The approach to these times varies significantly between various projects, depending on their complexity, scope, and resource availability.

  • Heavy Projects: response and resolution times are typically longer due to the complexity of the system, involvement of multiple teams, and thorough testing processes. A defect might take several days or more to resolve, depending on its severity and impact.
  • Light Projects: response and resolution times are much quicker, as the scope is smaller and workflows are more agile. Defects are typically acknowledged and resolved within a few hours to a few days.

Fixed response and resolution times streamline defect management, enhance project efficiency, and help deliver high-quality products on schedule.

Defect Workflows​

The defect management workflow is crucial for tracking and resolving defects efficiently. While the basic principles of defect workflows remain the same, the approach differs between various projects due to differences in complexity, team size, and project scale. The complexity of the project determines the number of steps and detail required in the defect workflow.

  • Heavy Projects: workflows are more structured, with multiple teams involved and detailed steps for defect categorization, prioritization, and resolution.
  • Light Projects: have a simpler, quicker process, with fewer formal reviews and a more flexible approach to defect management.

Defect Statuses​

Defect statuses in a defect management workflow represent the various stages a defect goes through from identification to closure. These statuses help track the defect’s lifecycle, ensuring transparency and clarity for all stakeholders involved.

  • Heavy Projects: the defect statuses in these projects are likely to be more granular, with additional sub-statuses and a formal review process at each stage.
  • Light Projects: the defect statuses are typically simpler and faster to manage. There are fewer formal reviews, and team members often wear multiple hats, allowing for a quicker resolution process.

Commonly Used Defect Statuses

  1. To Do/New: Defect is logged and waiting for initial action.
  2. Open: Defect is acknowledged but not yet started.
  3. In Progress: Defect is actively being worked on.
  4. In Review: Fix is completed and undergoing peer or lead review.
  5. Ready for Testing: Fix is approved and awaiting testing.
  6. In Testing: Fix is being verified by the QA team.
  7. Blocked: Progress is halted due to external factors or dependencies.
  8. On Hold: Work on the defect is paused temporarily due to changes in priorities or awaiting input.
  9. Done/Resolved: Fix has been successfully tested and marked as resolved.
  10. Closed: Defect is fully resolved, verified, and formally closed.
  11. Reopened: Defect is reopened after resolution due to an ineffective fix.
  12. Rejected: Defect is invalid, logged in error, or out of scope.
  13. Deferred: Defect is acknowledged but deferred for future releases.
  14. Duplicate: Defect is identified as a duplicate of an existing issue.

Adaption of defect statuses

  • Heavy Projects: most statuses are utilized to provide clear tracking and accountability. Passive statuses like "Blocked" and "Deferred" are crucial for managing dependencies, while completed statuses like "Done," "Closed," and "Rejected" ensure proper resolution and traceability.
  • Light Projects: only essential statuses are used, focusing on progress and resolution. Passive statuses like "Blocked" or detailed steps like "In Review" may be excluded, prioritizing speed and simplicity over detailed tracking.

Resolution​

Resolution in the defect management process refers to the steps taken to address and finalize a defect, ensuring it is appropriately handled, validated, and closed. The resolution process aims to confirm the defect has been fixed or otherwise addressed to meet project requirements and expectations.

The resolution field in defect management tools explains why a defect is closed or rejected, distinguishing outcomes (e.g., fixed, accepted) from issues still in progress. It applies only to completed stages, not active defects, ensuring clarity in defect management.

Recommended Resolution Values for Projects

  1. Unresolved: Indicates an open defect that has not yet been addressed.
  2. Fixed: The defect has been resolved with code changes and verified.
  3. Accepted: The issue is acknowledged by the business but will not be addressed as it is deemed acceptable.
  4. Cannot Reproduce: The defect could not be replicated during testing or debugging.
  5. Not a Defect: The reported issue is not classified as a defect (e.g., working as intended).
  6. Duplicate: The defect is identical to another reported issue and is cross-referenced.
  7. Won’t Fix: The defect is acknowledged but will not be resolved due to strategic or resource constraints.

The approach to resolution differs between various projects due to variations in scale, complexity, and team structures.

  • Heavy Projects: prioritize traceability and accountability throughout the resolution process, ensuring that each defect is documented and resolved comprehensively.
  • Light Projects: prioritize speed and efficiency, with streamlined processes and minimal documentation. Resolution is typically handled by smaller, flexible teams with fewer formalities.

Root Cause​

The root cause in the Defect Management process identifies the underlying reason for a defect after investigation, helping to prevent future issues. The root cause field in a defect management tool records the fundamental reason for a defect, determined through investigation. It helps teams identify patterns, prevent recurring issues, and improve overall quality. This field is typically filled when a defect is resolved or closed.

Typical Root Cause Values

  1. Coding Issue: Errors or bugs in the code implementation.
  2. Configuration Issue: Problems with system or application configuration settings.
  3. Deployment Issue: Failures or errors during software deployment.
  4. Design Gap: Flaws or oversights in the system or feature design.
  5. Development Gap: Unimplemented or poorly implemented requirements by the development team.
  6. Duplicate Defect: A defect logged more than once by mistake.
  7. Environment Issue: Problems in testing or deployment environments, such as server crashes or setup errors.
  8. Incorrect Test Data: Use of invalid or incorrect data during testing.
  9. New Request: Additional requirements introduced after the initial scope.
  10. Not a Defect: An issue incorrectly classified as a defect due to misunderstanding.
  11. Performance Issue: Problems with system speed or efficiency, either due to code or environment.
  12. Requirements Gap: Missing or ambiguous requirements leading to defects.
  13. Third party issue: issue of 3rd party systems used by the product.
  • Heavy Projects: is formal and involves multiple stakeholders (e.g., developers, test leads, business analysts). It addresses complex issues like coding errors, design gaps, environment problems, or deployment failures, aiming for long-term improvements.
  • Light Projects: root cause analysis is quicker and less formal, often handled by a single team member. It focuses on immediate issues like coding mistakes or incorrect test data, with minimal documentation but still aimed at resolving recurring problems.