Stages of debugging Types of questions
you can ask
Types of activities to support pupils learning this step
1. What do you expect
should
happen?
What should it do?
Have you explained
this to your partner?
Model how to work out what should happen using a similar program.
Talk through how you can decompose your program into manageable parts. Then for each part talk
through what you expect should happen in that part before checking what actually happens.
In explaining what some code should do, pupils will often realise the error they have made.
See Rubberduck debugging.
It can be useful to sketch out what you expect.
If you created an algorithm, model how to debug this, the bug may be in the algorithm!
2. Find out what really
happens.
What happens?
Which part are you
checking now?
How about just checking this part?
Can you split this up
somehow?
How do you know you
are only checking that
bit?
Model how to ‘Wolf fence’ and break down what is being checked into parts.
Model how to look very carefully and just test one part of a program at a time. E.g. if looking at a simple
Scratch game where a moving character scores points, first focus on the control of the movement and
test this, before moving onto the score.
Show how to choose what values to test and be systematic and how to record (informally) what is
happening.
Use examples of tiny differences between things, highlight observational skills, for example play find the
difference.
Model how to test different input data. Encourage pupils to be logical and try the smallest and largest
values they can think of.
Test all the values that are possible for some pieces of code. E.g. if pupils have created a game which
accepts input from the keyboard to control a rocket flying round a planet, have they tested up, down, left
and right work? What about an unexpected key?
Award ‘You tested it’ awards - even if there was no bug!
Stages of debugging Types of questions
you can ask
Types of activities to support pupils learning this step
3. Find out where it went
wrong.
Where did it go wrong?
How can we work out
what is OK?
How can we make it
simpler to check?
Have you explained
the bug to someone
else?
Have you added comments to your code so
you know what it does
where?
Did you use meaningful names for variables?
What have you tested
so far?
What kind of error do
you think it might be?
Could it be an error in
your algorithm (logic)?
Model how to look carefully at your code and focus on one section at a time (decompose).
Add comments to the code as you write it - so that when you come to debug you remember what each
bit is supposed to do.
Use meaningful variable names, if this was not done when the program was written, then do this during
debugging to show how it helps us understand our code.
What can we change?
What have you tried?
Why did that not work?
Have you looked at
one that works?
Have you talked to
someone whose code
works for that bit?
Have you looked at
the class checklist of
common bugs?
Model how to make small changes and test again.
Model how sometimes a logical error may need you to return to the design - the algorithm.
Have examples of commonly used code or useful code blocks on display. Encourage pupils to check
here before they ask for help.
Have an agreement where pupils code in pairs and try to fix the bug with their partner before they then
perhaps consult with their ‘support pair’.
Plenaries and starters can be used to show code that has progressively more complicated bugs, modelling with pupils how to debug this code.
Pupils might be encouraged to use help systems associated with software or to search web-based forums for support.
Create a debugging poster of bugs your class often find or of the steps to debug or have a ‘You fixed a
bug’ class awards.
4. Fix it.
Meaningful variable names make debugging much easier.
Model how to think about the type of error, is it an error in the logic (possibly the algorithm or the code).
Model how to use logic to try to work out what the difference is between what should happen and what
did happen, so that pupils can work out where things went wrong.
Provide lessons where pupils practise debugging different types of bugs, so that they become better
able to tackle these when they come across them in independent programming activities.