Correct identified errors

Program Testing and Maintenance – Correcting Identified Errors

1. Why Error‑Correction Matters (Cambridge 9618)

• Testing and maintenance together account for the majority of a software‑development project’s effort.
• Correctly locating, analysing and fixing faults demonstrates understanding of:
  • Information representation (binary, BCD, ASCII/Unicode, floating‑point)
  • Communication (network protocols, IP addressing, client‑server interaction)
  • Hardware and processor fundamentals (registers, ALU, interrupt handling)
  • System software (OS services, language translators, IDE tools)
  • Security & data integrity (validation, encryption, checksums)
  • Ethical and professional responsibilities (documentation, licensing, AI use)

2. Classification of Errors

3. Systematic Error‑Correction Process

1. Reproduce the Fault
   • Run the program with the exact inputs that triggered the problem.
   • Record output, error messages, system state (e.g., memory usage, CPU load).
2. Isolate the Faulty Segment
   • Use an interactive debugger: set breakpoints, step through, inspect the call stack.
   • If a debugger is unavailable, insert temporary print/console.log statements.
   • Apply “binary search of code”: comment out or disable halves of the program to narrow the location.
3. Analyse the Cause
   • Compare actual behaviour with the intended algorithm or specification.
   • Check variable values, loop counters, condition evaluations, and data‑type limits.
   • Consider whether the fault originates from representation, hardware, or security mechanisms.
4. Design & Apply a Fix
   • Address the root cause, not just the symptom.
   • Prefer minimal changes that preserve existing functionality and maintainability.
   • When relevant, update configuration files, API contracts, or hardware settings.
5. Retest Thoroughly
   • Run the original test case and a set of additional edge‑case tests.
   • Execute the full regression suite to confirm no new faults have been introduced.
   • Include performance and security tests where appropriate.
6. Document the Change
   • Update inline comments, version‑control commit messages, and the defect‑tracking record.
   • State the reason for the change, the modules affected, and any impact on performance, security or usability.
   • Reflect on ethical considerations (e.g., not exposing stack traces in production).

4. Core Debugging Techniques (Cambridge‑aligned)

• Print‑Debugging – Insert statements to display variable values at key points.
• Interactive Debugger – Step‑by‑step execution, watch windows, modify variables at runtime.
• Binary Search of Code – Systematically comment out or disable code blocks to locate the fault.
• Static Analysis – Linters, SonarQube or language‑specific tools to detect unused variables, unreachable code, or security vulnerabilities.
• Profiling – Measure CPU, memory and I/O usage to pinpoint performance errors.
• Regression Testing – Re‑run all previously passing tests after a fix.
• Formal Verification (where appropriate) – Use assertions or model‑checking for safety‑critical modules.

5. Syllabus‑Linked Foundations for Error Correction

5.1 Information Representation

• Binary, Octal, Hexadecimal – Essential for bit‑wise debugging and overflow detection.
• BCD (Binary‑Coded Decimal) – Frequently used in financial applications; conversion errors are common.
• ASCII & Unicode – Mis‑encoding leads to garbled text; test with characters outside the basic ASCII range.
• Floating‑Point Representation – Rounding errors, loss of precision, special values (NaN, ±∞). Test extreme values and use tolerance checks.

5.2 Communication

• Network Fundamentals – LAN/WAN concepts, OSI/TCP‑IP layers, packet structure.
• IP Addressing & Subnetting (IPv4/IPv6) – Interface errors often stem from incorrect address configuration.
• TCP vs. UDP – Reliability differences affect error‑handling strategies.
• DNS, HTTP/HTTPS, Cloud APIs – Validate responses, handle time‑outs, and check version compatibility.

5.3 Hardware

• CPU, RAM (SRAM, DRAM), ROM (PROM, EPROM, EEPROM), cache, and I/O devices.
• Embedded systems and micro‑controllers – limited resources increase the likelihood of overflow and timing errors.
• Buffers and queues – common sources of off‑by‑one and race‑condition bugs.

5.4 Processor Fundamentals

• Von Neumann architecture – shared memory for instructions and data.
• Registers (general‑purpose, program counter, stack pointer, status registers).
• ALU operations – arithmetic overflow, sign‑extension errors.
• Control Unit & Instruction Cycle (Fetch‑Decode‑Execute) – timing‑related bugs often arise here.
• Interrupt handling – ensure proper saving/restoring of registers.

5.5 System Software

• Operating‑System Services – memory management, file I/O, process scheduling, security, device drivers.
• Utility Software – debuggers, profilers, version‑control tools, build systems.
• Language Translators – assemblers, compilers, interpreters; syntax errors are caught here, while runtime errors may depend on the runtime environment.
• Integrated Development Environments (IDEs) – code completion, static analysis, automated testing support.

5.6 Security & Data Integrity

• Confidentiality, integrity, authentication – essential for safe error handling (e.g., not exposing stack traces in production).
• Encryption basics (symmetric, asymmetric) – verify that decryption errors are handled gracefully.
• Checksums, parity bits, CRC – automatic detection of data‑corruption errors.
• Input validation & sanitisation – prevent injection attacks and buffer overflows.

5.7 Ethics & Ownership

• Professional responsibility – accurate documentation of defects and fixes.
• Intellectual property – respect licences when re‑using libraries or code snippets.
• Impact of AI and automation – ethical considerations when delegating testing to AI tools.

6. Maintenance Phases and Typical Errors Addressed

7. Worked Example – Logical Error in a Factorial Function

Original C‑style code (intended to compute n! for a positive integer n):

int factorial(int n) {
    int result = 1;
    for (int i = 1; i < n; i++) {   // error: loop stops before n
        result *= i;
    }
    return result;
}

The function returns (n‑1)! because the loop condition uses i < n. The correction is to make the upper bound inclusive.

1. Identify the Fault – Loop condition excludes the final multiplication by n.
2. Correct the Code

   int factorial(int n) {
       int result = 1;
       for (int i = 1; i <= n; i++) {   // corrected condition
           result *= i;
       }
       return result;
   }
   

3. Retest – Verify with representative cases:
   • n = 1 → 1
   • n = 5 → 120
   • n = 7 → 5040
4. Document – Add a comment and record the change:

   // Loop uses <= to include n in the product (computes n!)
   

8. Diagram – The Error‑Correction Cycle

9. Summary Checklist for Correcting Errors (Exam‑Ready)

• Can the error be reproduced reliably with the same inputs?
• Is the faulty code isolated to a small, testable unit (function, module, or hardware interface)?
• Have you identified the root cause rather than merely the symptom?
• Is the fix minimal, preserving existing functionality and adhering to coding standards?
• Have all relevant test cases—including edge cases, performance tests, and security checks—been re‑executed?
• Is the change fully documented in code comments, version‑control logs, and the defect‑tracking system?
• Have you considered the impact on related syllabus areas (representation, hardware, security, ethics)?