Activity:  Fix a Defect

Note: implementation and modification of components takes place in the context of configuration management on the project. Implementers are provided with a private development workspace (see Activity: Create Development Workspace) in which they do their work, as directed by Artifact: Work Orders. In this workspace, source elements are created and placed under configuration management, or modified through the usual check out, edit, build, unit test, and check in cycle (see Activity: Make Changes). Following the completion of some set of components (as defined by one or more Work Orders and required for an upcoming build), the implementer will deliver (see Activity: Deliver Changes) the associated new and modified components to the subsystem integration workspace, for integration with the work of other implementers.

Stabilize the Defect

The first step is to stabilize the defect (i.e. a symptom), to make it occur reliably. If you can't make the defect occur reliably, it will be almost impossible to locate the fault.

Then try to narrow down the test case by identifying which of the factors in the test case make the defect occur, and which factors are irrelevant for the defect. To find out if a factor is irrelevant, change the factor in question and execute the test case. If the defect still occurs, this factor can probably be eliminated.

If successful, you should finish with at least one test case that causes the defect to occur, and also some idea of what factors are related to the occurrence of the defect.

Locate the Fault

The next step is to execute the test cases that cause the defect to occur and try to identify where in the code the source of the fault is. Examples of ways to locate a fault are:

• Narrow down the suspicious region of the code. Test a smaller piece of the code; remove a piece of the code, and rerun the test cases. Continue to remove pieces of code, as long as the defect still occurs. Eventually you will have identified where the fault can be found.
• Use the debugger to step through the code line-by-line, and monitor the values of interesting variables.
• Let someone else review the code. See the Activity: Review Code for more information.

Fix the Fault

When the fault has been located, it is time to fix it. This should be the easy part. Here are some guidelines to keep in mind:

• Make sure you understand the problem and the program before you make the fix.
• Fix the problem, not the symptom; the focus should be on fixing the underlying problem in the code.
• Make one change at a time, because fixing faults is in itself an error-prone activity, it is important to implement the fixes incrementally, to make it easy to locate where any new faults are occurring from.

When the fault has been fixed, add a special test case that verifies this particular fault.