Defect Repair Procedure

This procedure describes how TMC developers manage defect correction.

1. A defect is identified or change request approved. (Note: coding style violations are not counted as defects.)
2. Verify the defect is not previously reported.
3. Defect report (or approved change request) is entered into the Trac defect tracking system.
   Complete the following fields as indicated:
   1. Short Summary: A succinct but meaningful definition of the problem.
   2. Type: defect
   3. Description: A complete description of the problem. Explain in detail the specific steps to reproduce the problem.
   4. Priority: select how urgent it is to fix this defect. Functionality that is needed immediately is Urgent, functionality that is seldom used is Low.
   5. Severity: select how severely this defect affects product use.
      • Critical - The defect results in the failure of the software, locks up the system, causes loss of data, or makes the system unusable.
      • Major - The defect does not result in a failure, but causes the system to produce incorrect, incomplete, inconsistent, or otherwise inappropriate results, or the defect impairs the systems usability. There may or may not be an appropriate work around.
      • Minor - Same as above except the desired processing results are easily obtained by working around the defect, or the defect occurs infrequently enough to not impact normal use of the system.
      • Trivial - The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or other trivial problem.
   6. Component: Select the effected component from the drop down list (e.g., CPTMS, CAD server, etc).
   7. Version: If the defect is in a versioned component, enter the version number.
   8. Owner: Fill in the username of the programmer responsible for this component, or leave blank.
   9. CC: if you leave Owner blank then CC to the lead programmer.
   10. Preview, and make corrections if necessary.
   11. Create ticket.
4. Implementation manager reviews new defect reports daily and reassigns defect to a programmer. Do not assign the defect to more than one person or it will "disappear".
5. Programmer uses Trac to "accept" the defect. (If the person reporting the defect is the programmer who will fix it, you don't have to wait for the Implementation manager to assign it to you.)
6. Programmer obtains current version of system source code from SVN.
7. Programmer writes an automated Unit test (or System Test) which reveals the defect. If it is infeasible to write an automated test, write a manual test and add it to the system test cases. Cross-reference the test case to the defect number, e.g. put the defect number in the test case method name (E.g., TestDeckBug26).
8. Programmer isolates and repairs defect. Write a comment with the defect number.
9. Programmer runs Unit test (or System Test) on repaired code. Optionally, Programmer runs any relevant integration or system tests.
10. Programmer updates from SVN, then commits the repaired unit and associated test. Write a commit message according to your team policy, and include "Fixes defect #x." (The '#' character makes a link to the ticket.)
11. In the Comments field of the defect ticket, put a Trac link to the SVN revision number of the change just committed. (E.g., r217)
12. Programmer closes the defect in the tracking system. (Under action, choose "resolve as: fixed". Under Completion Status, choose "done".).
13. Implementation manager reviews resolved defects on a daily basis and informs relevant personnel, e.g., Documentation team, other developers, Release Manager, etc.

---