Detecting and Tracking Software Errors

HOME   More Articles

In order to detect errors the software testing team must:

  • examine the internal structure and design


  • examine the functional user interface


  • examine the design objectives


  • examine user requirements


  • execute the code

To track and record errors, thorough documentation procedures are a must. This must be done from the Requirements Analysis phase up to and including the Acceptance Testing phase. Documentation serves as a historical record — this can help predict what type of faults/errors the code is likely to have, and clusters of certain types of faults/errors can warn us the design may need to be rethought or requirements may have to be changed. Many organizations use statistical analysis to track errors. IBM uses an “orthogonal tracking” approach. Here, faults/errors are places in categories that, together, paint a picture of which parts of the development process needs attention. Orthogonality classifies a particular error or fault as belonging to exactly one category. If the fault or error belongs to more than one, the meaning of measurement is lost (Software Engineering: Theory and Practice; Pfleeger, S.L.).

Here’s an example of IBM’s Orthogonal Defect Classification:

  1. Fault/error type: Function
    Meaning: affects capability, end-user interface, product interface


  2. Fault/Error type: Interface
    Meaning: fault in interacting with other components or drivers via calls, macros, control blocks, parameter lists


  3. Fault/Error type: Checking
    Meaning: fault in program logic that fails to validate data and values properly before they are used


  4. Etc…

Finally, automating the testing procedure (through the use of CASE-type software engineering tools or other applications) should also make the tracking procedure more accurate and reliable.

More Software Testing information:

top of page