# Debugging

> CIE A-Level Computer Science · 9618
> Source: https://www.owlsprep.com/study/cie-9618-u12-debugging/

This module covers core debugging concepts for CIE A-Level Computer Science, including types of program errors, common systematic methods, and techniques to locate, diagnose, and resolve bugs in software code.

**Prerequisites:** [Basic software development life cycle](https://www.owlsprep.com/study/cie-9618-u12-software-development-lifecycle/); Fundamental programming concepts

## Learning objectives

- Classify the three main types of program error
- Describe common debugging methods and tools
- Apply a systematic process to locate and fix bugs
- Distinguish between testing and debugging in exams

## Types of Program Errors

Before debugging can begin, errors must be classified by their type, as this guides your choice of debugging approach. CIE 9618 regularly examines your ability to distinguish between the three core categories of program error.

**Core Program Error Types** — Three main categories of error encountered during software development, each with distinct symptoms and requiring different debugging approaches.

*Example:* Syntax errors, runtime errors, logic errors

- **Syntax errors**: Violations of the programming language's grammar rules, caught by compilers or interpreters before execution starts. The program will not run at all.
- **Runtime errors**: Errors that occur during program execution, causing the program to crash or abort unexpectedly before it completes.
- **Logic errors**: Errors where the program runs to completion without crashing, but produces incorrect output or behaves in an unexpected way.

**Worked example:** Classify the following error: A Python program divides a user's input by zero, and stops execution with a `ZeroDivisionError` message.

1. Step 1: Confirm the program compiled/interpreted successfully and started execution before failing.
2. Step 2: Note the outcome: the program stopped execution unexpectedly rather than producing wrong output.
3. Step 3: Match the symptoms to the error type definition.
4. Conclusion: This is a runtime error.

> **Exam tip:** Always check if the program runs at all: if it runs but output is wrong, it is a logic error, not a runtime error.

## Common Debugging Methods

Debugging is often confused with testing, but the two processes have distinct goals. Testing confirms that a bug exists; debugging locates and fixes that bug. There are several established methods for locating bugs efficiently.

**Debugging** — The systematic process of locating, identifying, and resolving bugs (errors) in a computer program.

*Notation:* Testing finds bugs; debugging fixes them.

- **Manual walkthrough**: Tracing through code line by line manually to follow execution flow and variable values.
- **Print statement debugging**: Adding temporary print statements to output variable values at key points in code.
- **Binary search debugging**: Dividing code into halves repeatedly to narrow down the location of a bug efficiently.
- **IDE tool debugging**: Using built-in IDE tools to pause execution and inspect program state at runtime.

**Worked example:** A 100-line program crashes halfway through execution. How would you use binary search to locate the bug?

1. Step 1: Add a print statement or breakpoint at the midpoint of the code (line 50).
2. Step 2: Run the program. If it crashes before reaching line 50, the bug is in the first 50 lines. If not, it is between lines 51–100.
3. Step 3: Repeat the process on the half that contains the bug, narrowing the range each time.
4. Step 4: Stop when you have narrowed the bug down to a single line or small code block.

## Debugging Tools

Modern integrated development environments (IDEs) include powerful built-in debugging tools that make locating runtime and logic errors much faster than manual methods. CIE expects you to know the function of the most common tools.

**Breakpoint** — A marker set on a line of code that tells the debugger to pause execution when it reaches that line, allowing you to inspect the current program state.

- **Watch expression**: A variable or expression added to the debugger watch list, so its current value is displayed whenever execution is paused.
- **Step into**: Execute the next line of code, and if that line calls a function, pause execution inside the function.
- **Step over**: Execute the next line of code, and run through any called functions without pausing inside them.
- **Step out**: Continue execution until the current function returns, then pause again.

**Worked example:** A function `calculateTotal(price, tax)` returns an incorrect total of \$102 instead of the expected \$120 for input price=100, tax=0.2. How would you use a breakpoint and watch to find the error?

1. Step 1: Set a breakpoint on the first line inside the `calculateTotal` function.
2. Step 2: Run the program with the test inputs price = 100, tax = 0.2.
3. Step 3: When execution pauses, add `price`, `tax` and the running total to the debugger watch list.
4. Step 4: Step through each line of the function one by one, checking the total value after each step to see where it deviates from the expected value.
5. Step 5: Once the incorrect line is identified, fix the error and re-test the function.

## Systematic Debugging Process

Effective debugging follows a repeatable systematic process rather than guessing what the problem is. This reduces time spent and ensures the bug is fully resolved, with no new issues introduced.

1. Reproduce the bug consistently with a minimal test case.
2. Form a hypothesis about where the bug is located based on error symptoms.
3. Test the hypothesis by inspecting code and program state.
4. If the hypothesis is wrong, form a new hypothesis and repeat testing.
5. Once the bug is located, implement a fix for the error.
6. Test the fix to confirm the bug is resolved and no new bugs were introduced.

**Check your understanding**

Check your understanding of core concepts:

1. What is the first step in systematic debugging?

   - Fix the bug
   - Reproduce the bug
   - Form a hypothesis
   - Set a breakpoint

   *Why:* You must first be able to consistently reproduce the bug to investigate it properly.

2. Which of these is a logic error?

   - Missing semicolon that stops compilation
   - Division by zero that crashes the program
   - Calculating percentage by dividing by 10 instead of 100, outputting 1000% instead of 10%
   - Forgetting to close a bracket in Python

   *Why:* A logic error runs without crashing but gives the wrong output, which matches this case.

> **Exam tip:** CIE often tests the distinction between testing and debugging: remember testing finds bugs, debugging fixes them.

## Common pitfalls

- **Wrong:** Confusing testing with debugging in exam answers
  - Why it fails: Testing only confirms a bug exists, it does not locate or fix it
  - Correct: Always clarify: testing identifies the presence of bugs, debugging locates and resolves them
- **Wrong:** Classifying a logic error as a runtime error because output is wrong
  - Why it fails: Runtime errors always cause the program to crash or abort, logic errors do not
  - Correct: If the program runs to completion but gives wrong output, it is a logic error
- **Wrong:** Skipping reproducing the bug and jumping straight to changing code
  - Why it fails: Without consistent reproduction, you cannot confirm if your fix actually worked
  - Correct: Always create a minimal test case that reproduces the bug before starting debugging
- **Wrong:** Confusing step into and step over in debugger descriptions
  - Why it fails: Mixing these up is a common exam mistake that costs marks
  - Correct: Step into enters a function to debug inside it; step over runs through the function without pausing
- **Wrong:** Not retesting after fixing the bug
  - Why it fails: Fixing one bug can introduce a new bug in a different part of the program
  - Correct: Always run all relevant tests after fixing a bug to confirm the fix works

## Cheatsheet

| Category | Item | Key Exam Fact |
| --- | --- | --- |
| Error Type | Syntax Error | Caught before execution, program won't run |
| Error Type | Runtime Error | Occurs during execution, crashes program |
| Error Type | Logic Error | No crash, wrong output, hardest to debug |
| Debug Tool | Breakpoint | Pauses execution to inspect program state |
| Debug Tool | Step Into | Pauses inside called functions for inspection |
| Debug Tool | Step Over | Runs through functions without pausing |
| Debug Method | Binary Search | Fast bug location in large codebases |
| Process Step | First Step | Reproduce the bug consistently |

## What's next

Debugging is a core practical and theoretical skill for CIE A-Level Computer Science, building on your understanding of the software development life cycle and program design. The systematic approach to bug location and resolution you learned here applies to all programming paradigms, and will be useful both for exam questions and your own practical programming coursework. After mastering debugging, you can deepen your knowledge of software quality by exploring different types of software testing, advanced error handling techniques, and version control tools that support debugging in collaborative development environments.

- [Software maintenance](https://www.owlsprep.com/study/cie-9618-u12-software-maintenance/)
- [Software Project Management](https://www.owlsprep.com/study/cie-9618-u12-software-project-management/)
- [Computational thinking & problem solving (including declarative, OO and AI)](https://www.owlsprep.com/study/cie-9618-u13-overview/)

---

From [OwlsPrep](https://www.owlsprep.com) — free study guides for A-Level, IB, AP and IGCSE, written against the official syllabus. Canonical page: https://www.owlsprep.com/study/cie-9618-u12-debugging/