I – of course – use a risk-based approach in my testing, meaning that checking the exact phrasing of error messages is very far down on my prioritised list of test tasks. As long as the message is relevant and understandable I am happy enough.
I have an old favourite error message that it is hard to compete with. A couple of years ago I was using a free software that was really fantastic, but would occasionally and unpredictably crash, in which case the simple yet suitable error message ‘Click OK to crash’ was shown. There was an OK button, the only thing you could do was to click it, and yes – the program crashed.
The error message completely failed to give me any clues as to why the program crashed, but it certainly told me very clearly what was going to happen, and it put a smile on my lips, even though I would loose my unsaved work. In my opinion simplicity in error messages is definitely preferable, unless you are actually going to put some useful information in there. Do not try to obscure the fact that you messed up by using tech lingo or providing a pointless novel.
I also remember painfully well working on my thesis late one night when I encountered the king of all error messages: Kernel panic. No ambiguity there – I panicked too.
If there is a point hiding in here it is this: error messages are important, spend some time on them. Think usability, not debugging.
