22.7. Keeping Test Records
Aside from making the testing process repeatable, you need to measure the project so that you can tell for sure whether changes improve or degrade it. Here are a few kinds of data you can collect to measure your project:
Administrative description of the defect (the date reported, the person who reported it, a title or description, the build number, the date fixed) Full description of the problem Steps to take to repeat the problem Suggested workaround for the problem Related defects Severity of the problem�for example, fatal, bothersome, or cosmetic Origin of the defect: requirements, design, coding, or testing Subclassification of a coding defect: off-by-one, bad assignment, bad array index, bad routine call, and so on Classes and routines changed by the fix Number of lines of code affected by the defect Hours to find the defect Hours to fix the defect
Once you collect the data, you can crunch a few numbers to determine whether your project is getting sicker or healthier:
Number of defects in each class, sorted from worst class to best, possibly normalized by class size Number of defects in each routine, sorted from worst routine to best, possibly normalized by routine size Average number of testing hours per defect found Average number of defects found per test case Average number of programming hours per defect fixed Percentage of code covered by test cases Number of outstanding defects in each severity classification
Personal Test Records
In addition to project-level test records, you might find it useful to keep track of your personal test records. These records can include both a checklist of the errors you most commonly make as well as a record of the amount of time you spend writing code, testing code, and correcting errors.
|
No comments:
Post a Comment