Correct identified errors

Published by Patrick Mutisya · 14 days ago

Cambridge A-Level Computer Science 9618 – 12.3 Program Testing and Maintenance

12.3 Program Testing and Maintenance

Objective: Correct Identified Errors

In this section we examine how to locate, analyse and correct errors that have been identified during testing or in later maintenance phases. The process combines systematic testing techniques with disciplined debugging and documentation.

1. Types of Errors

Error TypeTypical CauseCommon SymptomsCorrective Action
Syntax ErrorIncorrect use of language grammar (missing semicolon, mismatched brackets)Compiler/Interpreter stops with an error messageRefer to the error message, correct the offending line, re‑compile
Logical ErrorFaulty algorithm or incorrect conditionProgram runs but produces wrong outputTrace the algorithm, use print‑debugging or a debugger to inspect variable values, adjust logic
Runtime ErrorInvalid operation during execution (division by zero, null reference)Program aborts or throws an exceptionValidate inputs, add exception handling, ensure resources are correctly allocated
Interface ErrorMismatch between modules or external systemsIncorrect data exchange, crashes at module boundariesCheck API contracts, data formats, and version compatibility
Performance ErrorInefficient algorithm or resource leakageSlow response, high memory/CPU usageProfile the program, replace with more efficient algorithm, optimise data structures

2. Systematic Approach to Correcting Errors

  1. Reproduce the Error

    • Run the program with the same input conditions.
    • Record the exact output and any error messages.

  2. Isolate the Faulty Segment

    • Use a debugger to set breakpoints around the suspected code.
    • Insert temporary print statements if a debugger is unavailable.

  3. Analyse the Cause

    • Compare the actual behaviour with the intended algorithm.
    • Check variable values, loop counters, and condition evaluations.

  4. Apply a Fix

    • Modify the code to address the root cause.
    • Prefer minimal changes that preserve existing functionality.

  5. Retest

    • Run the original test case and additional edge cases.
    • Confirm that the error no longer occurs and no new errors appear.

  6. Document the Change

    • Update comments, version control logs, and the defect tracking record.
    • Note the reason for the change and any impact on other modules.

3. Debugging Techniques

  • Print‑Debugging: Insert statements that output variable values at key points.
  • Interactive Debugger: Step through code line‑by‑line, inspect the call stack, and modify variables at runtime.
  • Binary Search of Code: Comment out or disable halves of the program to narrow the error location.
  • Static Analysis: Use tools that examine source code for common mistakes (unused variables, unreachable code).
  • Regression Testing: After a fix, run the full suite of previously passed tests to ensure no regression.

4. Maintenance Phases and Error Correction

Maintenance is divided into three recognised phases. Each phase has its own emphasis on error correction.

PhasePurposeTypical Errors AddressedKey Activities
Corrective MaintenanceFix faults that cause the program to deviate from its specifications.All error types identified after deployment.Bug tracking, root‑cause analysis, patch development, regression testing.
Adaptive MaintenanceModify the system to work in a changed environment (new OS, hardware, regulations).Interface errors, configuration mismatches.Impact analysis, code refactoring, compatibility testing.
Perfective MaintenanceImprove performance, readability, or add minor enhancements.Performance errors, code‑smell, usability issues.Profiling, code optimisation, documentation updates.

5. Example: Correcting a Logical Error

Consider the following fragment intended to compute the factorial of a positive integer n:

int factorial(int n) {

int result = 1;

for (int i = 1; i < n; i++) {

result *= i;

}

return result;

}

The program returns result = (n‑1)! instead of n!. The error lies in the loop condition.

  1. Identify the Fault: The loop runs while i < n, so it stops before multiplying by n.
  2. Correct the Code:

    int factorial(int n) {

    int result = 1;

    for (int i = 1; i <= n; i++) { // changed condition

    result *= i;

    }

    return result;

    }

  3. Retest: Verify with test cases such as n = 1, 5, 7. Expected results are \$1\$, \$120\$, \$5040\$ respectively.
  4. Document: Add a comment explaining the inclusive upper bound and record the change in the version log.

6. Suggested Diagram

Suggested diagram: Flowchart showing the error‑correction cycle – Detect → Isolate → Analyse → Fix → Retest → Document.

7. Summary Checklist for Correcting Errors

  • Can the error be reproduced reliably?
  • Is the faulty code isolated to a small, testable unit?
  • Have you identified the root cause rather than just the symptom?
  • Is the fix minimal and does it preserve existing functionality?
  • Have all relevant test cases (including edge cases) been re‑executed?
  • Is the change fully documented in code comments and maintenance records?