Problem-solving

Debug by Testing One Hypothesis at a Time

When a program, spreadsheet, or practical procedure fails, changing many things at once can hide the cause.

When a program, spreadsheet, or practical procedure fails, changing many things at once can hide the cause. A hypothesis-driven approach narrows the problem and preserves what you learn from each test, even when the first guess is wrong.

Reproduce and describe

Write the expected behavior, actual behavior, and smallest conditions producing the difference. Save a copy or use a reversible change before experimenting. For a spreadsheet, identify the first cell with an unexpected value. For a process, find the earliest point where the output diverges. A repeatable small case is easier to inspect than a large messy failure described only as everything is broken.

Form a specific hypothesis

Predict what you would observe if one suspected cause were responsible. Perhaps a date is stored as text or a function receives an empty value. Inspect the relevant input or intermediate result rather than changing unrelated settings. Make one controlled change when feasible and record the outcome. If the prediction fails, revise the hypothesis. Random changes may occasionally fix the symptom while leaving you unable to explain or safely preserve the fix.

Verify the repair broadly enough

After resolving the small case, test ordinary use and relevant boundary cases. A fix for empty input should not break valid input. Remove temporary diagnostic changes and record the cause in plain language. Beginners can use a simple expected, observed, hypothesis, test table. Experienced troubleshooters can automate meaningful regression checks where appropriate. The depth of verification should match the consequence and scope of the change rather than expand indefinitely without a remaining concern.

Put it into practice

Put it into practice

  1. Choose a reproducible error.
  2. Reduce it to a small case and state one hypothesis with a predicted observation.
  3. Run a single focused check, record what it ruled in or out, and verify the eventual repair on an ordinary and a boundary case.
Take this with youFocused hypotheses and informative tests turn troubleshooting into accumulated knowledge rather than a sequence of unexplained changes.

Sources & further reading

Practical examples and exercises are original StudyMaster learning activities. Read about our editorial approach.

Open your reading list →

Keep your curiosity going

A few more useful ideas.

More in problem-solving →
Problem-solving

Work Backward from a Desired Result

When a starting point feels unhelpful, reasoning backward can reveal the conditions a solution must satisfy.

2 min read