A Systematic Debugging Log for Programming Assignments

Debugging improves when you treat a failure as a question to investigate rather than a prompt to change random lines. A small log of expected behaviour, observed behaviour and tests can save time and make your final documentation credible. Start with a reproducible case, narrow the possible causes and change one relevant thing at a time. The goal is to understand why a fix works, not merely to make one sample input pass.

Reproduce the failure

Write the input, environment, exact steps and expected output. Note the actual output and any error message. If the problem disappears when rerun, check timing, state, dependencies and hidden assumptions instead of declaring victory. Reduce the case to the smallest input that still fails. A minimal example can reveal whether the defect is in parsing, calculation, data access or display.

Read the error and trace

A traceback or compiler message identifies where failure became visible, which may differ from where the wrong value originated. Follow the call path and inspect relevant state. Avoid suppressing exceptions simply to hide the symptom. Add temporary logging or a debugger breakpoint at a point that can distinguish competing explanations. Never log passwords, tokens or private user data in an assignment project.

Form and test a hypothesis

Write “I expect variable X to be empty because branch Y did not run,” then design the smallest check that would confirm or reject it. If evidence contradicts the hypothesis, update it. Change one factor at a time so you can attribute any improvement. Copying a suggested fix without understanding its preconditions often creates another failure. Keep a record of experiments that did not work; they eliminate possibilities.

Add a regression test

When the defect is understood, turn the failing input into a test that would have caught it. Include a normal case and a boundary case where useful. Tests should check behaviour, not simply repeat the implementation line. If the assignment has no automated test framework, document a repeatable manual test with expected results. Run relevant existing tests after the fix to detect side effects.

Explain the resolution

Record the root cause, change and evidence that the behaviour now matches the requirement. Remove temporary logging and inspect edge cases. If a library or environment version contributed, document it for the assessor. A concise debugging note can show sound engineering judgment without turning the final report into a diary of every attempted edit.

Worked example

A function may work for positive numbers but fail for zero because a condition uses “greater than zero” when the requirement includes zero. The debugging log records input 0, expected result, actual failure and the branch taken. A targeted condition fix plus tests for -1, 0 and 1 demonstrate that you understood the boundary rather than merely hiding the error.

A debugging experiment log

Use five columns: time, hypothesis, test, observed result and next decision. Suppose a sorting function produces the wrong order for duplicate values. First record a minimal input with two equal values and their original positions. Then inspect the comparison function rather than changing output formatting. If you suspect unstable sorting, write a test that checks the required tie behaviour. A failed hypothesis is useful when the test rules out one mechanism; note it and move on. When the root cause is found, add a regression test and run the broader suite. In your final project report, summarise the defect and evidence of correction rather than dumping every console output. This log demonstrates a repeatable reasoning process that a reviewer can understand.

Checklist before you submit

Save a reproducible failing case.
Use the error trace to choose a hypothesis.
Change one factor and record the outcome.
Add a test for the failure and relevant boundaries.

Questions students ask

Should I print every variable?

Usually not. Inspect values that distinguish your current hypotheses, and remove sensitive or temporary logging afterward.

What if a fix passes one test but breaks another?

Revisit the requirement and root cause; a local patch may have ignored a related case.