Lesson Overview | Tirohanga Whānui
Pairs use the same four-column debug protocol on three concrete Scratch problems, then apply it to one behaviour in their own project.
Seminar focus: reason about the failure
Ākonga diagnose a broken procedure by argument and evidence rather than by trial and error, and say what test would settle it.
- Unplugged Seminar move: Stated hypothesis, then the single test that would confirm or kill it
- Evidence it produces: A named cause with the test that distinguishes it from the alternative
Lesson at a Glance | Te Hōtaka
Ngā Whāinga Ako | Learning Intentions
- Locate the first mismatch between expected and actual behaviour.
- Change one likely cause and repeat the same test.
- Use a debug log to justify an improvement.
Do Now: Where is the first mismatch?
7 minExpected: a sprite moves right 10 steps each time the right arrow is pressed. Actual: the sprite jumps right before any key is pressed. Which is more likely: the wrong event block, wrong movement amount, or wrong sprite costume? Explain the smallest useful test.
Activity 1: The four-column protocol
10 min| Expected | Actual | One change | Retest result |
|---|---|---|---|
| State the observable result. | Describe, do not judge. | Name one block or value. | Use the same input again. |
Rule: do not rewrite the whole script. A focused change makes the evidence interpretable.
Activity 2: Three-bug lab
25 minA · Escaping sprite
Expected: moves forever but stays visible.
when flag clickedforever → move 10 stepsTest adding if on edge, bounce inside the loop and setting left-right rotation.
B · Missed win
Expected: says “Win!” once score reaches at least 5.
if <score = 5> then say “Win!”Test with score jumping 4 → 6. Compare = 5 with > 4.
C · No reset
Expected: each game starts at score 0.
when flag clickedforever → change score by 1Test placing set score to 0 before, then inside, the loop. Explain the difference.
- Complete a four-column row for each bug before changing code.
- Build or reason through the smallest fix.
- Swap one diagnosis with another pair and try to disprove it.
🔑 Three-bug lab — diagnoses, fixes and retest results (kaiako)
Each diagnosis below is derivable from the code shown on the card, so pairs can reach it on paper without a device. Ask for the four-column row before they change anything — a correct fix with no recorded evidence has not been debugged, it has been guessed at.
A · Escaping sprite. Diagnosis: the forever loop moves the sprite but nothing ever turns it around, so it travels in one direction until it reaches the edge and stays pinned there. Nothing is broken inside move 10 steps — the fault is a missing instruction, not a wrong one. Smallest fix: put if on edge, bounce inside the forever loop, after the move. Retest: the sprite crosses, turns and comes back indefinitely. Setting rotation style to left-right stops it appearing upside down after the first bounce — a presentation improvement, not the bug.
B · Missed win. Diagnosis: = 5 is true at exactly one value. If the score jumps 4 → 6 it is never equal to 5, so the win never fires even though the goal ("at least 5") was passed. This is a boundary-condition bug: the code is correct at and below 5 — a score of 3 or 4 should not win, and does not — and wrong only above 5, where the win is skipped entirely. Smallest fix: compare > 4 (equivalently, at least 5). Retest: jump the score 4 → 6 and the message fires. Ask why testing only with score = 5 would have hidden this — that is the transferable point.
C · No reset. Diagnosis: the variable is never initialised, so the score carries over from the previous run and each game starts higher than the last. Smallest fix: set score to 0 before the forever loop. The contrast worth teaching: placing it inside the loop resets the score on every iteration, so it changes by 1 and immediately returns to 0 and never climbs. Same block, same value, opposite behaviour — position is part of the instruction. Retest: run twice and confirm the second game starts at 0.
Marking the protocol, not the fix: a strong four-column row names what was expected, what actually happened, one change made, and what the retest showed. A pair who fixes B by guessing > 4 without recording the 4 → 6 test has the right code and the wrong method.
Activity 3: Test your own project
11 minChoose one behaviour from Lessons 3–5. Write the expected result, run a repeatable input three times, record the actual result and make one change only if evidence supports it. If no bug appears, test an edge case instead.
Whanaungatanga: The navigator asks “What did the evidence show?” before suggesting a fix.
Exit: Debugging claim
7 min“The most useful evidence was ___ because it ruled out ___.” Add one debugging habit you will carry into the project build.
🎯 Curriculum Alignment
Applying principles of form, function, accessibility, and usability during development and evaluating outcomes against specifications
Focused tests compare function against an observable specification. See the unit map.
📦 Materials & Resources
Resources already provided: protocol table and three bug cases above; Scratch, devices and project logs. Cases can be solved entirely on paper if devices are unavailable.
📊 Assessment and Success Criteria
Paearu Angitu | Success Criteria: I can identify a first mismatch, log one justified change, repeat the same test and explain what the retest proves.
♿ Inclusion, entry and extension
Entry: Diagnose one printed bug with two possible fixes. On-level: Complete all cases and one own-project test. Extension: Design a minimal test that distinguishes two competing causes. Use predictable roles, visual logs and non-screen tracing for neurodiverse learners or those managing screen load.
📋 Teacher Planning Snapshot
“It doesn’t work” is not yet evidence. Require expected and actual behaviour in observable language. Celebrate good diagnosis even when the first fix fails. Lesson 7 uses the same protocol during the assessed build.
📚 Sources and teaching basis
Scratch for Educators. Ako and manaakitanga shape the debug dialogue: knowledge is shared, while critique stays attached to the code and evidence.