Defect Repair Procedure
This procedure describes how CPE 309 teams manage defect
correction.
- A defect is identified or change request approved.
- Verify the defect is not previously reported.
- Defect report (or approved change request) is entered into the
Trac defect tracking system.
Complete the following fields as indicated
Short Summary: A succinct but meaningful definition of the problem.
Type: defect
Description: A complete description of the problem.
Explain in detail the specific steps to reproduce the problem.
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.
Component: Select the effected component from the drop down list
(e.g., GUI, database, user manual).
Version : Enter the Release number (1 or 2)
Assigned to: leave blank. Do not assign the defect to anyone.
CC: fill in the implementation manager's username (or select from the list
if available).
Submit the issue.
- Implementation manager reviews new defect reports daily and
reassigns defect to a programmer and checks the notification by e-mail
checkbox.
- Programmer begins work on defect by entering Start repair time
in Remarks field of defect report, E.g. Start repair: 4/5/03 10:20AM
- Programmer obtains current version of system source code from
SVN. Run the LOC counter to obtain current LOC.
- Programmer writes a JUnit test (or System Test) which reveals
the defect. Cross-reference the test case to the defect number,
e.g. put the defect number in the test case method name (TestServerBug26).
- Programmer isolates and repairs defect.
- Programmer runs JUnit test on repaired code. Optionally,
Programmer runs any relevant integration or system tests.
- Programmer checks out defective module from SVN, installs the
repair, and checks it in.
- Programmer determines New and Changed LOC required for the
repair.
- Programmer adds the JUnit test to the unit test repository (or
System Test to the Test Matrix).
- Programmer records repair finished time in Remarks field , E.g.
End repair: 4/5/03 11:45AM.
Programmer calculates repair time as difference between Start and End
times: E.g., Repair Time: 85 min.
Programmer enters New and Changed LOC in Remarks field.
- Programmer closes the defect in the tracking system. (Under action,
choose "resolve as: fixed").
- Implementation manager builds the system with the corrected
code and produces a build report.
- Test team runs the JUnit tests and System tests (as part of a
regression suite) on the current build.
- Test team produces test report showing which tests were run.
- Implementation manager reviews resolved defects on a daily
basis and informs relevant personnel, e.g., Documentation team,
other developers, Release Manager, etc.
Document History
4/20/08 JD Changed Elementool to Trac. Changed CVS to SVN.
1/28/07 JD Added more status options.
2/12/04 JD Added numbering. Added "System Test" to step 6, 11, and 15.
4/8 JD Revised for Elementool.
4/3 JD Revised bug assignment procedure.