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.
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.
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:
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:
When the fault has been fixed, add a special test case that verifies this particular fault.