Most of the things you can directly affect are things that happen in every test run, so best-case will include them.
Slower test runs will include events that don't happen on every test run (the computer is busy doing something else), so editing the code has less effect on them, and possibly none at all if it's completely unrelated.
Maybe those other events causing slowdown should be investigated too? But usually you want to look for a way to make them happen every time before working on them.
Best-case over a large number of runs is the correct way to approach the ideal running time of the task in this case, as you can eventually hit a run that didn't get impeded by anything.
Consider the following runs of two systems:
system A: 10s, 10s, 10s, 10s, 10s, 10s, 10s, 5s
system B: 6s, 6s, 6s, 6s, 6s, 6s, 6s, 6s
Which one is faster? (Hint: don't say system A)