Since debugging is essential "test in a way that enables you to figure out WHAT is wrong", this is a problem :-(
Interesting to bring up the relationship between testing and debugging, although they are quite different things.
The purpose of a test is to evaluate the current condition of something, whereas debugging is a process to understand and fix something that isn't working as expected.
Having said that, systematic debugging typically involves a series of tests, where the outcome of each tests guides the next step in the process.
But this leads to another distinction: Systematic debugging vs non-systematic debugging.
Both systematic and non-systematic debugging can be successful. Indeed, CSGuy's "inspiration" debugging is an example of non-systematic debugging. It's entirely reliant on an "aha!" insight, and as such, there is no process or structure, and so there is nothing that can be taught there.
Many posters who appeal for help with their programs I suspect are also non-systematic debuggers, as they will often say things like "I am completely out of ideas -- please help guys", suggesting that an idea or inspiration as to what the problem might be is necessary to continue.
Sound systematic debugging methods, OTOH, do not rely on "new ideas" or "insight" proceed, as they generally progress by elimination through test and verification (or not) of the debugger's assumptions. The systematic approaches when formalised resemble algorithms. If applied diligently, they will (almost) always succeed, although perhaps converge slowly as a process. Less inspiration and more perspiration, as Edison might have said.
So to clarify, my suggestion is that *systematic* forms of debugging might be something useful to try to teach. Further, I suspect trying to teach any of the various non-systematic approaches wouldn't be very useful, as a) they are probably self-evident anyway, and b) they are usually what have already been exhausted by the time a poster asks for help. (Although I have my suspicions that some posters haven't applied *any* debugging method -- they wrote the code, compiled it, and found it didn't work as expected, and then were at a complete loss as to how to proceed.)
In conjunction with the "process" side of systematic debugging, specific tips and techniques particularly suitable for the Arduino environment could be discussed. Also, the more esoteric aspects of the subject like dealing with so-called "Heisenbugs" might be worth some discussion.
Anyway, just putting it out there (hence Bar Sport!)