When this happens and the "user would not normally do that" discussion comes up I always remind the developers that most end users of our products are not developers and do not necessarily follow a developers logic when using our product(the I am an idiot approach) and if I found it they probably will as well. It seems no one takes any pride in their work anymore (grab the money kick the product out the door).
just my 1.5 cents worth
But in the end doesn't it all come down to BEER? Beer is the ultimate answer to all questions in the universe so yes the answer to your question is BEER.
Happens all the time to me too. One of our support team workers showed me something he found on one of our forms. Sure enough it was a bug.
I told my boss I wanted to spend some time looking at the form. I found a very critical flaw in the design of the form. One bug turned into 5 or 6. Which turned into 25 to 30 after I had checked all the similar forms. Since programmers copy code all the time I knew the same bugs would be in his other forms.
Just another excellent reason to implement exploratory testing!
Just yesterday we had a Strawman document that was to be converted over to a Detailed Requirements Document next week, so I called a meeting of my group and we started to review it. Looks like it will have to be completely rewritten. There are many contradictions and vague statements as well as it not being detailed at all, but actually a high level requirements document. We were ready to just let it go by until I noticed one incorrect item.
We've learned our lesson on testing documents and will continue to review them critically.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~
I do agree with your comment, although commercial reality does not allow this is many cases.
In general I have experienced most of what everyone has stated, but this case would not have been possible to investigate if the software was working correctly in the first place.
I regard test documents to be of minimal use as they are usually based on how a product is supposed to work. I agree they must be followed more as a formaility, but best case scenario with a test document will be all the major functions work as expected. This does not mean that there are no bugs, in fact quite the opposite can be found when you do explority testing or free range testing. Even well written test docs with detailed tests covering exception handling issues will still miss some of the finer points on how the software behaves.