I simply wanted to add that you also blew my mind in a conversation, where you stated: "That's checking!" when we discussed a testing problem. That was quite a while ago. Just like James, I couldn't follow you on this – yet. This series was pretty necessary and I immediately understood what you were going to say from the first article in it. Keep up with it, I think it's promissing to clear up that discrepancy.

P.S.: And you always write too much for me to be able to keep up with it.

Should you check the fix anyhow? (which is double checking).

Maybe. At least now we have some vocabulary for that.

Perhaps I was pairing with the programmer, and witnessed her coding and running the check.

Perhaps there's now a check that I've observed that's been added to the continuous integration suite.

Maybe I've had a conversation with the programmer that provides me with sufficient information to start with a variation on the original test idea.

Maybe the condition for the reported problem is now the subject of a whole suite of automated checks.

Only you can decide in your context—and whichever way you decide, your decision will be heuristic, maybe just right, but also subject to failing or being otherwise sub-optimal.

When testing the fix…You mean "checking"?

Nope. But thank you for asking.

When I'm testing a fix, I hope that my focus is on testing, rather than checking. Better yet, I'd like to working be in the kind of culture where I can be confident the programmer will do the checking, or make me aware of what he did and didn't check, so that I can apply my focus to testing.

Thanks for the comment!

—Michael B.

"There's an analogy in software, "It works on my machine." "See? It works on my machine." "Just like I told you; it works on my machine."

Famous words said by a developer "It compiled, so it must be okay". A perfect check.

"In an environment where the bug report is vague or your programmers are known or suspected of being unreliable with their bug fixes or you know that the programmer has not created an automated check, then what you're describing -confirming that the exact problem is fixed- might indeed be a very good idea."

And in the situation where the programmer is known to be reliable and he/she created an automated check… will checking the automated check, including the result be enough to accept the fix? Or should you check the fix anyhow? (which is double checking).

"…(When testing the fix, I might start by trying to reproduce the problem as exactly as I could…"
You mean "checking"?