Here's a program that's supposed to average two scores, written in AP pseudocode:
avg ← score1 + score2 / 2
DISPLAY (avg)
If score1 = 90 and score2 = 70, this displays 125, not 80. The program runs perfectly — no crash, no complaint — and produces a confidently wrong answer. (Division happens before addition: 90 + 35.)
Would you have caught it? More importantly: what kind of error is this, and what testing strategy would catch it? By the end of this lesson you'll answer both in seconds — and you'll know why "it ran without errors" is the most dangerous sentence in programming.
Nobody writes a full program top-to-bottom in one sitting. The CED describes development as:
Two vocabulary terms the exam tests directly:
Real processes are both at once: you add pieces (incremental) in repeated design–test–revise cycles (iterative). If a question describes "testing each new feature before adding the next," that's incremental; "revising the design after user feedback each week" is iterative.
Program requirements describe how the program should behave — often including who the users are and what inputs/outputs matter. Requirements can be validated through testing.
Program documentation is a written description of how the program (or a piece of it) works and how to use it. Comments are documentation written inside the code, ignored by the computer.
Why the CED says documentation matters: - It helps other developers (and future-you) understand, use, and modify the code. - It's most useful when written during development, not slapped on at the end. - It should explain not just what code does but why design choices were made.
Your Create PT's Personalized Project Reference and written responses are, in essence, graded documentation — practice the habit now.
| Error type | What it is | Example | When it announces itself |
|---|---|---|---|
| Syntax error | Code breaks the language's grammar rules | DISPLAY(score — missing parenthesis |
Program won't run at all |
| Logic error | Program runs but produces unintended behavior | Averaging bug in the warm-up; using > instead of ≥ |
Never announces itself — only testing reveals it |
| Run-time error | Error that occurs while the program executes | Dividing by zero; accessing list index 11 in a 10-item list | Program crashes mid-run |
| Overflow error | A number is too large for the computer to represent | Adding 1 to the largest storable integer | Silent or crash, depending on system |
The exam's favorite move: describe a bug in words and ask you to classify it. The keys: - Won't run / "unexpected symbol" → syntax - Runs fine, wrong answer → logic - Crashes during execution on certain inputs → run-time - Number too big to represent → overflow
A test case is a specific input paired with the output you expect. Testing strategies the CED names:
Why boundaries? The averaging bug produces some wrong output for almost any input — but many logic errors only appear at edges. A discount program that fails only when the cart total is exactly $100 will pass every "normal" test. Test at 99, 100, and 101.
Debugging is the process of finding and fixing errors. Effective debugging combines: reproducing the error, isolating where it happens (hand tracing, extra DISPLAYs), fixing, and re-running all tests (a fix can break something else).
Problem: A program is supposed to display the number of students who passed. It runs without crashing but reports 3 when the correct answer is 5. What type of error is this?
Strategy: Ran fine? Yes. Wrong result? Yes. That combination has exactly one name.
Solution: Logic error — the program executes but behaves contrary to intent.
Interpretation: "Runs but wrong" = logic. No hesitation. The exam phrases this a dozen ways ("produces an unexpected result," "does not behave as intended") — same answer.
Problem: A program computes average ← total / count. It works on every class roster tested. On a brand-new empty roster (count = 0), the program halts with an error message during execution. What type of error, and what testing lesson does this teach?
Strategy: When does the error appear? During execution, on a specific input.
Solution: Run-time error (division by zero). The lesson: the developer never tested the boundary case of an empty roster. A test suite with "typical" inputs only will miss it; a suite with extreme values (0 students, 1 student, many students) catches it immediately.
Interpretation: Run-time errors are input-dependent — the program isn't universally broken, it's broken for certain inputs. That's exactly why the CED insists on testing a range of inputs including extremes.
Problem: This pseudocode should display the larger of two distinct values:
IF (a > b)
{
DISPLAY (a)
}
IF (b > a)
{
DISPLAY (b)
}
A student modifies it to handle the case where the values are equal, intending to display the shared value once. She changes the first condition to a ≥ b. What happens when a = 7, b = 7?
Strategy: Trace both IF statements with a = 7, b = 7.
Solution: First IF: 7 ≥ 7 is true → displays 7. Second IF: 7 > 7 is false → nothing. Output: 7, displayed once. The fix works for this case. Now the other two case categories. a = 3, b = 9: first IF false, second IF true → displays 9 ✓. a = 9, b = 3: first IF 9 ≥ 3 true → displays 9; second IF 3 > 9 false → nothing ✓. All three cases correct.
Interpretation: The habit to build: trace every case category — a > b, a < b, a = b. The student's fix survives all three. On the exam, proposed "fixes" often survive two categories and fail the third; you must check all of them, not stop at the first success.
Problem: A program awards free shipping for orders of $50.00 or more. Which set of test inputs best tests this feature? (A) $10, $20, $30 (B) $49.99, $50.00, $50.01 (C) $50, $500, $5000 (D) $0.01, $1000000, −$5
Solution: (B). The behavior changes at $50 — testing just below, at, and just above the boundary distinguishes ≥ 50 from > 50 (the classic off-by-a-penny logic error). (A) never reaches the boundary; (C) tests only the "free" side; (D) tests extremes but never the boundary where the rule lives.
Interpretation: Boundary testing isn't a vague virtue — it's aimed at the exact line of code where > vs ≥ matters.
x ← 3 +* 5. This is a:1. (D). The program won't run and the complaint is about a malformed expression (+*) — grammar violation = syntax error. Since it never ran, (A), (B), (C) are impossible.
2. (A). Crash during execution, on a specific input (no transactions → count of 0 → divide by zero) = run-time. (B): it ran for other users, so not syntax. (C): nothing suggests a too-large number. (D): a logic error wouldn't crash — it would report a wrong average.
3. (B). Bonus appears AT 5 means the condition includes equality when it shouldn't: ≥ 5 was written, > 5 was intended. (A) reverses the direction. (C)/(D): the program runs and doesn't crash — it's a logic error in the comparison.
4. (C). By definition: a value exceeding the largest representable integer = overflow. (D) is false — computers represent integers with finite storage.
5. (B). One piece at a time, each tested before the next = incremental. (A) would emphasize repeated feedback-revision cycles. Compare with #6.
6. (C). Repeated cycles of feedback and revision = iterative. Pair with #5 — the exam loves this contrast, and these two questions are the drill.
7. (B). Documentation during development helps collaboration and stays accurate as code evolves. (A)/(D): comments don't affect execution. (C): overclaims.
8. (B). Test case = input + expected output, stated before running. (C) describes the comparison you make when running the test, not the test case itself.
< 12 from a ≤ 12 implementation?9. (B). The rule changes at age 12; inputs at 11/12/13 straddle the boundary and expose < 12 vs ≤ 12. The others never isolate the boundary.
10. (A) and (C). Hand tracing and temporary output statements are the CED's named techniques for locating errors in running code. (B) is a last resort, not a location technique. (D) does nothing — comments are ignored at run time.
11. (C). The root cause is a loop iterating one time too many (off-by-one logic error), which manifests as a run-time error (invalid list index). The answer choice capturing both the cause and the crash is best — and yes, real bugs often chain this way.
12. (Model answer.) Error: my program computes sum / LENGTH(scores) without checking for an empty list. Classification: run-time error (division by zero) — it occurs during execution for a specific input. Test case: input = empty list; expected output = "No scores" message rather than a crash. Running this test reveals the crash and tells me to add an IF checking LENGTH(scores) = 0 first. (Any correctly classified error with a matching test case earns full credit — e.g., a logic error from order of operations with test input 90, 70 expecting 80.)
Answer letter distribution check: D, A, B, C, B, C, B, B, B, A+C, C — singles: A×1, B×5, C×3, D×1 + multi (A,C). B still heavy; will push A/D harder in Lesson 3.
12 (short response, WR 2(b)-style). Describe a specific error you could encounter in a program that averages a list of quiz scores, classify it (syntax/logic/run-time/overflow), and give one test case (input + expected output) that would reveal it.
Written Response 2(b) is "Errors and Testing" — on exam day you may be asked to describe an error you encountered while developing your Create PT program and how you fixed it, or to develop test cases for your own procedure. Build the habit now: while developing your PT, keep a short bug journal (what broke, what type of error, how you found it, how you fixed it). Three honest entries will make WR 2(b) trivial.
Also: your PT program must be developed iteratively — and the video + PPR reflect a working final increment. Test your procedure with boundary inputs (empty list! zero! largest value!) before you record the video; a crash during recording is a bad day.
Mini practice (WR 2(b) style): "Describe a test case you used on your program, the expected result, the actual result, and what it told you." Model: Input: an empty score list. Expected: the program displays "No scores entered." Actual: the program crashed with a division-by-zero error in my average procedure. This told me my procedure needed a condition checking whether the list length is 0 before dividing.
1. (D). The program won't run and the complaint is about a malformed expression (+*) — grammar violation = syntax error. Since it never ran, (A), (B), (C) are impossible.
2. (A). Crash during execution, on a specific input (no transactions → count of 0 → divide by zero) = run-time. (B): it ran for other users, so not syntax. (C): nothing suggests a too-large number. (D): a logic error wouldn't crash — it would report a wrong average.
3. (B). Bonus appears AT 5 means the condition includes equality when it shouldn't: ≥ 5 was written, > 5 was intended. (A) reverses the direction. (C)/(D): the program runs and doesn't crash — it's a logic error in the comparison.
4. (C). By definition: a value exceeding the largest representable integer = overflow. (D) is false — computers represent integers with finite storage.
5. (B). One piece at a time, each tested before the next = incremental. (A) would emphasize repeated feedback-revision cycles. Compare with #6.
6. (C). Repeated cycles of feedback and revision = iterative. Pair with #5 — the exam loves this contrast, and these two questions are the drill.
7. (B). Documentation during development helps collaboration and stays accurate as code evolves. (A)/(D): comments don't affect execution. (C): overclaims.
8. (B). Test case = input + expected output, stated before running. (C) describes the comparison you make when running the test, not the test case itself.
9. (B). The rule changes at age 12; inputs at 11/12/13 straddle the boundary and expose < 12 vs ≤ 12. The others never isolate the boundary.
10. (A) and (C). Hand tracing and temporary output statements are the CED's named techniques for locating errors in running code. (B) is a last resort, not a location technique. (D) does nothing — comments are ignored at run time.
11. (C). The root cause is a loop iterating one time too many (off-by-one logic error), which manifests as a run-time error (invalid list index). The answer choice capturing both the cause and the crash is best — and yes, real bugs often chain this way.
12. (Model answer.) Error: my program computes sum / LENGTH(scores) without checking for an empty list. Classification: run-time error (division by zero) — it occurs during execution for a specific input. Test case: input = empty list; expected output = "No scores" message rather than a crash. Running this test reveals the crash and tells me to add an IF checking LENGTH(scores) = 0 first. (Any correctly classified error with a matching test case earns full credit — e.g., a logic error from order of operations with test input 90, 70 expecting 80.)
Answer letter distribution check: D, A, B, C, B, C, B, B, B, A+C, C — singles: A×1, B×5, C×3, D×1 + multi (A,C). B still heavy; will push A/D harder in Lesson 3.
Exam tip: Error classification is a two-question decision tree. Did it run? No → syntax. Yes → did it crash mid-run? Yes → run-time (unless "number too large" → overflow). No → logic. Practice until this takes three seconds; the exam will spend three questions on it.