Debugging Techniques and Testing Strategies

Master the essential skills of finding and fixing errors in programs - key to CSEC IT success!

🎯 Learning Objectives

By the end of this article, you should be able to:

  • Explain the purpose of debugging and testing
  • Identify and apply basic debugging techniques
  • Design and use test data effectively
  • Detect syntax, logic, and runtime errors
  • Answer CSEC exam questions related to testing and debugging
1

Introduction to Debugging and Testing

💭 Real-World Analogy

Think of debugging like proofreading an essay - you're looking for spelling mistakes (syntax errors) and checking if your argument makes sense (logic errors). Testing is like asking a friend to read it - they might find problems you missed!

What's the Difference?

Debugging Testing
Finding and fixing errors in a program Checking if a program works correctly with different inputs
Happens after errors are found Happens systematically with planned data
Reactive - you respond to problems Proactive - you look for problems before they occur
Focuses on why it doesn't work Focuses on whether it works

📌 CSEC Tip

In exams, debugging questions often ask you to find and fix errors in algorithms, while testing questions ask you to choose appropriate test data or predict outputs.

2

What Is Debugging?

Debugging is the process of finding and removing errors (bugs) from computer programs. The term comes from 1947 when Grace Hopper found an actual moth causing problems in a computer!

When Does Debugging Happen?

  1. During development: When you write code and it doesn't work
  2. After testing: When test results show unexpected outputs
  3. During maintenance: When users report problems

Quick Debugging Exercise

BEGIN
INPUT age
IF age > 18 THEN PRINT "Adult"
ELSE PRINT "Minor"
END

What's wrong with this algorithm?

3

Common Debugging Techniques

1. Desk Checking (Dry Running)

Manually tracing through the algorithm with sample data, pretending you're the computer. Use paper to track variable values.

2. Using Trace Tables

A systematic way to record variable values at each step. Essential for CSEC exams!

Step i total Output
1: total = 0 - 0 -
2: FOR i = 1 TO 3 1 0 -
3: total = total + i 1 1 -
Loop: i = 2 2 1 -
total = total + i 2 3 -
Loop: i = 3 3 3 -
total = total + i 3 6 -
4: PRINT total 3 6 6

Trace table for: total=0, FOR i=1 TO 3, total=total+i, PRINT total

3. Breaking Programs into Smaller Parts

Test each section separately. For example:

  • Test input section alone
  • Test calculation section with fixed values
  • Test output section separately
🔍 Try It Yourself

Create a trace table for this algorithm with input 5:

BEGIN
INPUT n
factorial = 1
FOR i = 1 TO n
factorial = factorial * i
END FOR
PRINT factorial
END
4

Identifying Errors During Debugging

Syntax Errors: The Easiest to Find

Look for:

  • Missing punctuation (;, :, ,)
  • Misspelled keywords (PRITN instead of PRINT)
  • Mismatched brackets or quotes
  • Missing END IF, END WHILE, END FOR

Logic Errors: The Tricky Ones

Common logic error patterns in CSEC:

IF score > 50 THEN PRINT "Pass" // What if score = 50? Should be >=
FOR i = 0 TO 10 STEP 2 // Will run 6 times (0,2,4,6,8,10)
average = (mark1 + mark2) / 2 // Integer division? Use / 2.0 for decimal

Runtime Errors: The Crash Makers

Prevent these by:

  • Checking for division by zero
  • Validating input before using it
  • Checking array boundaries

⚠️ Common Caribbean Student Mistake

Many students forget to test with boundary values like 0, negative numbers, or very large numbers. Always ask: "What if the user enters...?"

5

What Is Program Testing?

Testing is systematically checking if a program works correctly using planned sets of data. Unlike debugging (which fixes known problems), testing tries to find unknown problems.

🏗️ Caribbean Example

Testing a program that calculates exam grades is like testing a recipe for Jamaican jerk chicken - you need to try it with different ingredients (inputs) to make sure it always tastes right (produces correct outputs)!

The Testing Mindset

  • Don't assume it works - prove it
  • Try to break the program (that's your job!)
  • Document what you test and what happens
  • Retest after fixing any errors

📝 CSEC Exam Alert

Testing questions often appear in Paper 2 (Problem-Solving). You might be asked to:

  1. Select appropriate test data for a given algorithm
  2. Complete a test plan table
  3. Identify what type of test data is being used
  4. Explain why certain test data should be used
6

Types of Test Data

✅

Normal (Valid) Data

Data that should work correctly

Example: Testing an age checker with age = 20

Purpose: Check normal operation

⚡

Extreme (Boundary) Data

Data at the limits of acceptability

Example: Testing "age ≥ 18" with age = 18 and age = 17

Purpose: Check edge cases

❌

Abnormal (Invalid) Data

Data that should be rejected

Example: Testing age input with "abc" or -5

Purpose: Check error handling

Complete Test Data Set Example

For a program that accepts scores 0-100 and prints grade:

Test Data Type Example Values Expected Result Why Test This?
Normal 75, 85, 92 Correct grades (B, A, A+) Normal operation check
Extreme 0, 50, 100 Boundary grades (F, C?, A+) Check grading boundaries
Abnormal -5, 105, "abc" Error messages Check input validation
🧪 Test Data Challenge

A program calculates discount: 10% for purchases over $100, 5% for purchases $50-$100, no discount below $50. What test data would you use?

7

Testing Strategies

Black-Box Testing

Testing without knowing the internal code. You only check inputs and outputs. Perfect for CSEC - you often test algorithms you didn't write!

Step-by-Step Testing

  1. Test inputs separately: Can the program accept all required data?
  2. Test calculations: Do the formulas work correctly?
  3. Test outputs: Is the display/formating correct?
  4. Test integration: Does everything work together?

Regression Testing

After fixing one error, retest everything! Fixing one bug might create another. This is especially important in CSEC practical projects.

📌 Caribbean Context Tip

When testing programs for Caribbean businesses (like a bakery inventory system), consider local factors: prices in EC$/TT$/JMD$, local holidays, local names and addresses.

Creating a Test Plan

Test # Input Data Expected Output Actual Output Pass/Fail
1 Age: 25 "Adult" "Adult" PASS
2 Age: 18 "Adult" "Minor" FAIL
3 Age: -5 Error message "Invalid age" PASS
8

CSEC Exam Practice Questions

📝 CSEC-Style Exam Questions

Instructions: Answer each question, then click "Show Answer" to check your understanding.

Question 1

What is the main purpose of using extreme (boundary) test data?

Show Answer
Answer: To check how the program behaves at the limits of acceptable input values.

Explanation: Extreme test data tests the boundaries between different conditions (like age = 17 and 18 for an "adult" check). This helps find off-by-one errors and ensures the program handles edge cases correctly.
Question 2

Identify TWO syntax errors in this algorithm:

BEGIN
INPUT hoursWorked
INPUT ratePerHour
salary = hoursWorked x ratePerHour
PRINT "Salary: " salary
END
Show Answer
Answer:

  1. Line 4: x should be * for multiplication
  2. Line 5: Missing operator between string and variable (should be PRINT "Salary: " + salary or use comma)

Corrected version:
BEGIN
INPUT hoursWorked
INPUT ratePerHour
salary = hoursWorked * ratePerHour
PRINT "Salary: ", salary
END
Question 3

A program accepts exam scores (0-100) and assigns grades: A (90-100), B (75-89), C (50-74), F (0-49). What test data would you use to check all grade boundaries?

Show Answer
Answer:

Test the boundaries for each grade:
  • F/C boundary: 49 (should be F) and 50 (should be C)
  • C/B boundary: 74 (should be C) and 75 (should be B)
  • B/A boundary: 89 (should be B) and 90 (should be A)
  • Extremes: 0 (lowest F) and 100 (highest A)

Also test normal data within each range (e.g., 65 for C, 85 for B) and abnormal data (e.g., -5, 105, "abc").
Question 4

What is the difference between debugging and testing?

Show Answer
Answer:

Debugging Testing
Finding and fixing known errors Systematically checking for errors
Reactive process Proactive process
Focuses on "why it doesn't work" Focuses on "whether it works"
Uses various techniques (trace tables, desk checking) Uses planned test data (normal, extreme, abnormal)
Question 5

Complete the trace table for this algorithm with input: 4

BEGIN
INPUT n
total = 0
FOR i = 1 TO n
total = total + i * 2
END FOR
PRINT total
END
Show Answer
Answer:

Step n i total
Input n=44--
total=04-0
Loop i=1410
total=0+1*2=2412
Loop i=2422
total=2+2*2=6426
Loop i=3436
total=6+3*2=124312
Loop i=44412
total=12+4*2=204420
PRINT total4420

Final output: 20

Question 6

Why should you test with abnormal (invalid) data?

Show Answer
Answer: To check how the program handles incorrect or unexpected inputs, ensuring it doesn't crash but instead provides appropriate error messages or validation.

Explanation: Programs in real use will encounter invalid data (users make mistakes!). Testing with abnormal data ensures:
  • The program doesn't crash or produce nonsense results
  • Error messages are helpful and appropriate
  • The program maintains data integrity (doesn't save invalid data)
  • Users are guided to correct their input
Question 7

What is desk checking (dry running) and when would you use it?

Show Answer
Answer: Desk checking is manually tracing through an algorithm step-by-step with sample data, recording variable values as you go, as if you were the computer executing the program.

When to use it:
  1. During algorithm design - to verify logic before coding
  2. When debugging - to find logic errors
  3. In CSEC exams - to answer trace table questions
  4. When reviewing code - to understand how it works
Question 8

A program calculates shipping cost: $5 for first kg, $2 for each additional kg. What would be good test data?

Show Answer
Answer:

Normal data: 3 kg → $5 + (2 * $2) = $9
Extreme data:
  - 1 kg (boundary) → $5
  - 1.1 kg (just over boundary) → $5 + (0.1 * $2?) Need to check how decimals handled
  - Very large weight (e.g., 100 kg) → $5 + (99 * $2) = $203
Abnormal data:
  - 0 kg or negative weight → Should give error
  - Non-numeric input (e.g., "two") → Should give error

Also test: 2 kg → $7, 0.5 kg (if allowed) → Need to check minimum charge.
9

Summary & Final Tips

Key Takeaways

  • Debugging = finding/fixing errors; Testing = checking for errors
  • Use trace tables for systematic debugging
  • Always test with normal, extreme, AND abnormal data
  • Boundary values are where most errors hide
  • After fixing errors, always retest everything

⚠️ Common CSEC Exam Mistakes

  • Forgetting to test boundary conditions
  • Using only normal test data
  • Not completing trace tables systematically
  • Confusing syntax errors with logic errors
  • Not testing with invalid inputs

📌 Final CSEC Advice

When you see a debugging/testing question in the exam:

  1. Read carefully - what exactly is being asked?
  2. Show your work - for trace tables, show each step
  3. Be systematic - don't jump to conclusions
  4. Check boundaries - this is where marks are often lost/won
  5. Think like a tester - try to break the algorithm!
Scroll to Top