Defect Resolution

Once the developers have acknowledged a valid defect, the resolution process begins.
The steps involved in defect resolution are as follows:
Prioritize Risk -- Developers determine the importance of fixing a particular defect.
Schedule Fix and Fix Defect -- Developers schedule when to fix a defect. Then developers should fix defects in order of importance.
Report Resolution -- Developers notify all relevant parties how and when the defect was repaired

1. Prioritize Risk:
The purpose of this step is to answer the following questions and initiate any immediate action that might be required:

• Is this a previously reported defect, or is it new?

• What priority should be given to fixing this defect?

• What steps should be taken to minimize the impact of the defect prior to a fix? For example, should other users be notified of the problem? Is there a work-around for the defect?

• A suggested prioritization method is a three-level method, as follows:

• Critical: Would cause the software to stop.

• Major: Would cause an output of the software to be incorrect.

• Minor: Something wrong, but it does not directly affect the user of the system, such as a documentation error or cosmetic GUI error.

2. Schedule Fix and Fix Defect:
Schedule Fix
Based on the priority of the defect, the fix should be scheduled. It should be noted that some organizations treat lower priority defects as changes. All defects are not created equal from the perspective of how quickly they need to be fixed.

Fix Defect
This step involves correcting and verifying one or more deliverables (e.g., programs, documentation) required to remove the defect from the system. In addition, test data, checklists, etc. should be reviewed, and perhaps enhanced, so that in the future this defect would be caught earlier.

3. Report Resolution:
Once the defect has been fixed and the fix verified, appropriate developers, users, and testers must be notified that the defect has been fixed along with other pertinent information such as:

• The nature of the fix,
• When the fix will be released, and
• How the fix will be released.

• As in many aspects of defect management, this is an area where automation of the process can help. Most defect management tools capture information on who found and reported the problem, and therefore provide an initial list of who needs to be notified.

• The developer identifies and fixes problems that caused the defects. Then the developer must record resolution information with the defects. The resolution information is then passed back to impacted parties. Computer forums and electronic mail can help notify users of widely distributed software.