Answer: Willie Sutton was a famous bank robber and the story is told that his answer to a reporter who asked him why he robbed banks was "...because that's where the money is."

It's the same with testing: one tests where the defects that have the greatest impact are most likely to show up, and that, of course, is at the GUI level. At the user's level, whatever that is.

In addition, the "meaning" of tests at the GUI level is probably more intuitive (if the GUI is a good one) so the actual tests are probably more intuitive than a unit-level test run on a low-level back-end function. And, furthermore, if a basic test of a GUI-accessed sequence is not a "real scenario" -- well, what is that functionality doing there in the first place? [Or, wouldn't that be a proper error detection: "useless function discovered in GUI"?]

If 80% of the testing is done on the GUI you might just want to turn around and ask, "Why wasn't it more like 95%?" Maybe 95%+ with some really complex scenarios that stress the entire application end to end.

For web-enabled applications, particularly those that are built with the newest application development methodologies and approaches like Ajax, testing from the GUI may be the only alternative. That's one reason why eValid's ease of use is of such great value in these cases.