Look at this page from a computer logbook. That is a real moth, taped in on 9 September 1947 after engineers found it stuck inside the Harvard Mark II computer. Today we still call mistakes in programs “bugs”, and finding and fixing them “debugging”.

Image source: File:First Computer Bug, 1947.jpg (Wikimedia Commons)
In this post:
- What bugs and debugging are, and why every programmer debugs
- Common bugs in Scratch programs
- A five-step method for finding and fixing bugs
- Three buggy Scratch projects to fix, including a bug-hunt you can do in this page
- Choosing good test data, a matching activity and a quiz
Bugs and debugging
A bug is a mistake in a program that stops it working the way it should. It might not run at all, it might crash, or (the sneakiest kind) it might run but give the wrong result. Debugging means finding the bug and fixing it. Before a program is used by other people, it must be prepared for execution: checked, tested and debugged so that it runs correctly every time.
Every programmer, even the best in the world, writes bugs. What makes a good programmer is being calm and organised about finding them.
Common bugs in Scratch
| Bug | Example | Fix |
|---|---|---|
| Missing block | The sprite never goes back to the start because nobody told it to. | Add the missing block in the right place. |
| Wrong order | say [You win!] comes before the check for the winner. | Drag the blocks into the right order. |
| Wrong number | change x by 10 on the left arrow, so the sprite goes the wrong way. | Change it to −10. |
| Wrong condition | mark > 50 when a mark of exactly 50 should pass. | Use <mark > 50> or <mark = 50>. |
| Not resetting | The score carries on from the last game. | set [score] to 0 when the green flag is clicked. |
| Wrong hat or wrong sprite | A script never runs because it is on the wrong sprite or under the wrong hat block. | Move the script to the right sprite, or change the hat. |
| Loop problems | Something happens only once because it is not inside a forever loop, or a loop never ends. | Put the check inside a loop, or fix the loop’s condition. |
A five-step debugging method
- Run it and watch. What exactly happens?
- Compare. What should happen? Write down the difference.
- Find where it goes wrong. Read the script block by block. Click single blocks to see what they do. Add a say block to show a variable’s value, or a wait to slow things down.
- Fix one thing at a time. If you change five things at once, you will not know which one worked.
- Test again, with normal, boundary and invalid data (see below). A fix can sometimes break something else!
Debug it! Project 1
What should happen: every time you click the cat, it should go to its starting position, move forward twice to the end position and then come back to the start. What actually happens: click the cat a few times and see. Then click See inside, find the bug and fix it in your own copy (click Remix).
Scratch project: DebugMe 1 by kunge.
Hint: the script is when this sprite clicked, go to x: −100 y: 0, then wait 1, move 130, wait 1, move 130, wait 1. Which instruction is missing at the end?
Debug it! Project 2
What should happen: you move the cat up and down with the arrow keys to get hit by the tennis ball, and each hit should add 1 to # of hits. Play it and watch the counter carefully. Does one hit add exactly 1?
Scratch project: DebugMe 2 by kunge.
Hint: the ball’s script checks if touching Sprite1 inside a forever loop. The loop runs many times every second, and the ball is touching the cat for several of those checks as it glides past. How could you make it count each hit only once? (One idea: after change [# of hits] by 1, add wait until <not <touching Sprite1?>>.)
Bug hunt: the grade calculator
This project gives a grade for a subject mark. It looks fine at first. Try marks such as 90, 60, 45 and 20 in the real project, and then try 100.
Scratch project: Grade calulator by kunge.
Try it: test, find and fix the bug
The script below is the same as the project’s. Test lots of marks (especially the boundaries, such as 100, 76, 75, 50, 49, 40 and 39) and compare what the program says with what it should say. When you have found the bug, choose a fix and test again.
when green flag clicked
ask [What's the subject mark?] and wait
set [mark] to (answer)
if <<(mark) > 75> and <(mark) < 100>> then think [That's a grade A!]
if <<(mark) > 49> and <(mark) < 76>> then think [That's a grade B!]
if <<(mark) > 39> and <(mark) < 50>> then think [That's a grade C!]
if <(mark) < 40> then think [That's a grade D!]The teacher’s rules: A = 76 to 100, B = 50 to 75, C = 40 to 49, D = 0 to 39.
Test mark:
| Mark | Expected | Program says | OK? |
|---|
Found the bug? Choose the fix:
Choosing test data
To prove a program works, don’t just try one “easy” value. Test three kinds of data. For a program that accepts marks from 0 to 100:
| Kind of test data | What it is | Examples |
|---|---|---|
| Normal | Ordinary values the program should handle easily | 35, 62, 88 |
| Boundary (extreme) | Values right at the edges of a range, where bugs love to hide | 0, 100, and 49 and 50 for the pass mark |
| Invalid (erroneous) | Values that should be rejected | −5, 150, “abc” |
Try it: sort the test data
A program accepts marks from 0 to 100, and 50 is the pass mark. Drag (or tap) each test value into the right box.
Normal
Boundary
Invalid
Watch: debugging in four steps
This video shows a simple step-by-step way to get rid of bugs in your code, with Scratch examples.
Video: How to Debug your Code in 4 Simple Steps! | Coding for Kids – STEM MC – https://www.youtube.com/watch?v=EWOYoQJrni4
Activity: match the bug to the fix
Try it: how would you fix it?
Choose the best fix for each bug.
| The score does not go back to 0 when a new game starts | |
| The sprite moves right when you press the left arrow | |
| A mark of exactly 50 says “Fail”, but 50 should pass | |
| The sprite checks for the edge once and then never again | |
| Nothing happens when you press space | |
| The cat says “You win!” before the race has even started |
Group practical: debug a set of programs
In groups, take the programs from your review in the last post (or projects your teacher gives you) that did not work properly. For each one: describe the bug, explain its cause, fix it, and list the test data you used to prove it now works. Use a table like this:
| Program | What went wrong | Cause | Fix | Test data used | Works now? |
|---|---|---|---|---|---|
Self-check quiz
Click the best answer. You get feedback straight away; only your first click counts towards your score.
1. A bug is…
2. Debugging means…
3. Why should you fix one thing at a time?
4. For marks from 0 to 100, which is boundary test data?
5. In the grade calculator, why did a mark of 100 get no grade?
6. The score keeps going up by lots for one hit. A good fix is to…
Related posts on islandclass.org
- Debugging – older notes on debugging
- Debugging in Context with Flowgorithm – more advanced: debugging a flowchart in Flowgorithm
For later, in Forms 4–5 (CSEC IT): these go deeper and are for when you reach CSEC Information Technology.
Next: This is the last post in the Forms 1–3 series. Well done! Next stop: CSEC Information Technology in Form 4.
Syllabus link: Forms 1–3 ICT curriculum, Module 5, Objective 5.18 – prepare a program for execution.
Attributions to media used in this post:
- First Computer Bug, 1947.jpg – Courtesy of the Naval Surface Warfare Center, Dahlgren, VA, 1988 – Public domain (via Wikimedia Commons)
- Video: How to Debug your Code in 4 Simple Steps! | Coding for Kids – STEM MC (YouTube)
- Scratch project: DebugMe 1 – kunge (Scratch)
- Scratch project: DebugMe 2 – kunge (Scratch)
- Scratch project: Grade calulator – kunge (Scratch)
Updates
2026/10/21
– Fixed the activity code so its buttons keep working.
© 2026 Vedesh Kungebeharry. All rights reserved.










