I happened to be reading Prof. Regehr's recent essay about trying to narrow down a GCC bug report he was preparing.
That led to the fascinating GCC wiki page on Testcase Reduction, a topic that I'm quite familiar with, but didn't realize that people approached in this fashion.
That led to the web page for the Berkeley Delta tool, maintained over at Tigris.org. I had no idea that this tool existed, so I'm glad to learn about it.
And that, finally, led to Prof. Zeller's book on systematic debugging. Amazon promises that my copy is in the mail.
It's dramatic how much difference there is between a good testcase and a poor testcase. A clearly described problem that has been reduced to the simplest set of reproduction steps gets fixed immediately; a vague and complex bug report languishes.
During the fix process, that clear test case can often suggest the location of the problem, and it aids in code review, as you endeavor to explain to your colleagues the problem, and the resolution. Then, after the bug is fixed, that test case turns into a regression test, and a code example in the documentation, and has a life of its own, above and beyond the result of enabling the bug fix.
If you are in the business, you are both a bug finder and a bug fixer; even if you think that learning to produce the best possible test cases is not your problem, it will be, eventually, so you should take the time to learn how to do it well.