Why restrict yourself to the easiest part of the process? Testing the restore of a single user DB, you'ev bypassed all sorts of fun and challenging things that will likely go to hell in a disaster. Like - restoring your AD, then restoring the system databases, then getting all of these databases to run, and run well.

You need to regularly do a full-fledged DR exercise. Starting with the "the data center blew up" exercise, and going up from there. At a previous employer, the CIO hired a consulting company to come up with 200 or so permutations of various "wrinkles", or rather additional issues we might need to be able to "survive". Things like - corrupted MSDB; missing backup (one or two sets); irretrievable AD restore, so revert to using the AD exports, etc.... or - the mainframe gateway's token ring card is gone, so the connectivity must be reestablished with new protocols over ethernet. In addition to all of the various "this user database's table x has been modified in x way".

What's more - time yourself. You HAVE to be able to do this fast, and preferrably on unfamiliar hardware, under adverse circumstances.

restores are important, but assuming conditions will be good when you need them is a surefire way to make sure you HAVE a problem. Try multiple permutations of various problems.