Demo: a full bug hunt from report to fix

Examples

Example 1: the whole hunt, step by step (simple)

Report: "The grade average is wrong when a student has a 0."

The program:

static double average(int[] grades) {
    int sum = 0;
    int count = 0;
    for (int grade : grades) {
        if (grade > 0) {
            sum += grade;
            count++;
        }
    }
    return (double) sum / count;
}

Step 1: read. Zero counts as a grade (confirmed by the report).

Step 2: reproduce. Compute by hand first: for {80, 0, 100} the sum is 180, there are 3 grades, so the expected average is 60.0. Run:

{80, 90, 100}  -> 90.0
{80, 0, 100}   -> 90.0

Expected for the second case 60.0, actual 90.0. A working case and a failing case: the failing one contains a 0.

Step 3: isolate. average is a single method; call it from a tiny main with just this array.

Step 4: hypothesize (first, weak). "Something in the loop ignores the 0." That is vague. Look at the clue: 90.0 equals 180 / 2. So the count was 2, not 3, while the sum was right (80 + 100 = 180 either way, since a zero adds nothing). A sharper hypothesis: the zero is not counted.

Step 5: test. Put a breakpoint on the if line. Add watches sum and count. Resume through the three passes, comparing with the hand trace:

The first mismatch is on pass 2: count did not increase. Step over the if on that pass with grade = 0: the highlight skips the block. Evaluate grade > 0, which is false. The condition rejects the 0.

Step 6: fix. Change grade > 0 to grade >= 0.

Step 7: verify. All three: the original {80, 0, 100} now gives 60.0; the working case {80, 90, 100} still gives 90.0; the edge case {0, 0} gives 0.0. (Real run after the fix.)

Example 2: the planned mistake (practical)

Suppose that at step 4 we skipped the thinking and, under time pressure, tried "maybe the count is too small", changing the last line to:

return (double) sum / (count + 1);

The real run printed:

{80, 90, 100}  -> 67.5
{80, 0, 100}   -> 60.0

The failing case now shows 60.0, the expected value: it looks fixed. But the case that worked now prints 67.5, which is wrong (it should still be 90.0). Why did one case improve? By accident: with a zero in the data, the real count (3) happened to be one more than the loop's count (2). The change fits that case only, and silently breaks every other.

How to recognize this mistake:

• You could not say why you made the change. (Our reason was "maybe".)
• You tested only the failing input.
• The watches would have disagreed: with the new formula, sum / (count + 1) no longer matches the hand trace for the working case.

Recovery: undo the change, return to the table of expected values, and go on from the hypothesis. This is the symptom fix from Lesson 1 made visible: it adjusts the answer for one input and leaves the cause (the condition) untouched.

Example 3: write the case note (realistic)

A short case note for a ticket or a pull request:

Bug: Class average ignored students with a grade of 0.
Reproduce: grades {80, 0, 100}. Expected 60.0, actual 90.0.
Isolated to: average(int[]), loop condition.
Hypothesis: "if (grade > 0)" skips zero, so count is 2 instead of 3.
Evidence: breakpoint in loop with watches sum and count; on the pass
          with grade = 0, count did not increase (condition false).
Fix: changed "grade > 0" to "grade >= 0".
Verified: {80,0,100} -> 60.0; {80,90,100} -> 90.0; {0,0} -> 0.0.
Open question: an empty array gives NaN (0 / 0 as double); decide the
          desired result separately.

The last line shows a good habit: you found an adjacent problem (an empty array printed NaN in our run) and recorded it instead of quietly changing more. One fix per change keeps the evidence clean.