Mastering Software Defect Management: Complete Lifecycle and Process Guide

Purpose

This document defines the software defect management process and related rules to ensure systematic and standardized handling of defects, thereby guaranteeing project development quality.

Scope

The process applies to defect management throughout the development lifecycle, providing guidance and standards for each phase.

Definitions

Defect (Defect) : A deviation existing in software that can be activated and exists statically within the software.

Bug : A manifestation of a defect that impairs normal operation.

Defect Lifecycle

See the diagram below for the defect lifecycle.

Defect Statuses

Active : Initial or re‑activated state; can be edited and assigned to an engineer.

Resolved : Defect has been fixed; system automatically re‑assigns to the creator.

Closed : After successful verification, the defect is closed; if it re‑appears, it is re‑activated.

Defect Handling Process

Create Issue : Any user can create a new issue (requirement or defect) in the defect management system, providing a clear description and appropriate options.

Assign Issue : Typically assigned to the project development lead, who may delegate to a module engineer; reassignment is possible with remarks.

Confirm Issue : Developers confirm whether the issue is a bug; if not, they note the reason and re‑assign to the creator.

Resolve Issue : Developers reproduce, fix, and verify the bug; upon successful verification, the status changes to Resolved and the system auto‑assigns back to the creator.

Verify Issue : The creator validates the fix; if verification passes, the bug is closed; otherwise, it is re‑activated.

Close Issue : Verified bugs are closed; if the bug recurs in later versions, it is re‑activated.

Special Handling

Customer Issue : Submitted by a customer or project manager, marked with [Customer Issue] in the title.

Dispute Handling : After six unsuccessful communications, the issue is escalated to the project manager for resolution.

Deferred Resolution : When fixing a bug is risky or time‑consuming, the developer requests deferment; the project manager marks the title with [Deferred] and sets the appropriate status.

Defect Management Tool

All defects are tracked in the defect management system to ensure traceability, data collection, trend analysis, and reporting.

Defect Attributes

Defect ID : Unique identifier for each defect.

Defect Type : Categorizes the defect based on its nature (design, UI, data, requirement, installation, performance, documentation, knowledge, security, optimization, other).

Severity : Impact level (Fatal, Severe, Normal, Suggestion).

Priority : Urgency for fixing (Immediate, Urgent, ASAP, Normal).

Occurrence Probability : Likelihood of recurrence (Always, Frequent, Occasional, Random).

Severity Levels

Fatal : Systemic failures that block development or testing.

Severe : Serious errors that do not halt testing.

Normal : Non‑critical issues that do not affect user usage.

Suggestion : Optimization recommendations discovered during testing.

Priority Levels

Immediate : Must be solved instantly (all fatal issues, release‑blocking problems).

Urgent : Must be solved before the next release (all severe issues, core functionality errors, obvious performance problems).

ASAP : General functional errors to be solved before release.

Normal : Non‑blocking issues that may remain unchanged.

Occurrence Probability

Always : 100% (e.g., 5 out of 5 tests).

Frequent : 30%–100% (e.g., 3‑4 out of 5 tests).

Occasional : 10%–30% (e.g., 2 out of 10 tests).

Random : <10% (e.g., 1 out of 15 tests).

Processing States

Confirming : Issue is under confirmation.

Resolving : Developer is analyzing or fixing the bug.

Reproducing : Attempting to reproduce the problem.

Verifying : Long‑term verification of intermittent issues.

Deferred : Set only by the project manager.

Solution Definitions

Fixed : Defect has been corrected and verified.

Duplicate : Same defect already exists.

Invalid : Not a problem or not reproducible.

Cannot Reproduce : Neither developer nor tester can reproduce after multiple attempts.

Deferred : Deferred by project manager after risk assessment.

Defect Description Guidelines

Title : Concise, accurate, using keywords (environment, action, object, phenomenon).

Reproduction Steps : Include preconditions, test steps, actual result, expected result; be clear, ordered, and quantified.

Attachments : Provide screenshots, logs, scripts, or videos to aid analysis.