Debugging Techniques

Overview

Today students debug their Microbit-style coding projects from the previous lesson by identifying what the code is doing versus what they intended. They will use systematic troubleshooting steps, then test and revise until the program works as expected.

Learning intentions

Students will be able to:

• explain how positive/negative outcomes or opposite behaviors can appear in real-world STEM contexts when code uses sign or direction
• identify likely causes of bugs (wrong logic, missing step, incorrect condition, or mismatched inputs/outputs)
• use a test-fix-repeat process to correct errors in a program
• describe why a change fixed the bug using evidence from test results

Success criteria

• I can pinpoint where my program’s behavior first differs from what I expected.
• I can change one part of the code at a time and retest to confirm the fix.
• I can explain the bug and the fix using specific observations (what happened and what I expected).
• I can make my project meet the given function goal (e.g., correct LED/buzzer output and correct handling of input/conditions).

Curriculum links

• Number system — interpret and use positive/negative numbers to describe opposite directions or values; explain the meaning of 0 in a situation (6.NS.C.5)
• Real-world problems by graphing points in all four quadrants; use coordinates/absolute value for distance with same coordinate (6.NS.C.8)
• Signs of numbers in ordered pairs as locations; recognize reflections across axes when signs change (6.NS.C.6b)
• Interpret and compute quotients of fractions and solve division word problems (6.NS.A.1) when students analyze how often an action should occur or distribute outputs evenly (This lesson’s core is debugging, but the troubleshooting explanations will explicitly connect to STEM contexts like direction, offsets from zero, and opposite behaviors.)

Lesson structure (45 minutes)

1. 0–5 min · Hook (Bug Spotting). Teacher displays a short “before” behavior description (or live demo): “LEDs blink, but not in the pattern we wanted.” Students do a quick think: What could be wrong—inputs, conditions, or ordering?

2. 5–12 min · Mini teach: Debugging cycle. Teacher models a 3-step loop: (1) observe the bug clearly, (2) locate the likely cause (check conditions/logic/variables), (3) change one thing and retest, recording results. Students fill a one-page “Debug Log” for their own project: expected behavior vs actual behavior.

3. 12–22 min · Guided debugging stations (teacher-led groups). Teacher assigns 2–3 students per group with mixed readiness and provides a “Debug Checklist” card (What should happen? What did happen? Where in the code control logic runs? Any sign/direction assumptions? Any off-by-one or missing line?). Students work on their prior project, using the checklist to identify the first failing step.

4. 22–32 min · Targeted fix: One-change retest. Teacher reminds: change one block/line at a time; retest immediately; circle the evidence that confirms the fix. Students select one bug, implement a single targeted correction, and update their Debug Log with “Changed ___ because ___.”

5. 32–40 min · Partner share: Evidence-based explanation. Teacher gives sentence starters on the board:

• “My code expected ___, but the program did ___.”
• “The likely bug was in ___ because ___.”
• “After I changed ___, the result matched ___.” Students practice explaining their fix to a partner and listen for missing evidence.

6. 40–45 min · Exit ticket (quick assessment). Students submit a short response: (1) What was your bug? (2) What did you change? (3) What test result proved it worked?

Resources

• Student devices with their previous project files loaded
• Debug Log printable (expected vs actual, likely cause, change, test result)
• Debug Checklist card (logic/conditions/order/inputs/variables)
• Sentence starters handout for partner explanation
• Optional: a class “Bug Types” anchor chart (missing step, wrong condition, swapped inputs, off-by-one, sign/direction error)
• Timer and grouping slips for peer-support teams

Assessment

• During stations: teacher observes whether students can identify the first place behavior diverges from expected
• Debug Log review: checks for evidence-based entries and “one change at a time” retesting
• Exit ticket: verifies students can name the bug, describe the fix, and cite a test result

Differentiation

• Grouping: students are placed in peer-support groups where one student shares strategies (not answers); teacher circulates to prompt slower teams with questions like “What did you expect at this step?”
• Support: provide a model Debug Log example and a checklist with checkboxes for common bug categories (wrong condition, missing step, order/sequence, variable mismatch).
• Extension: students attempt a “second bug” after fixing the first, then write a brief explanation comparing why the two bugs required different troubleshooting steps.
• EAL/SEN: sentence starters, visuals on the checklist, and allowing verbal recording of the debug explanation before writing.