Support procedures. We all have 'em, some more formal than others. These are the things that support or dev does on a system in the field when it's in trouble. Sometimes they are scripts, sometimes they're a set of commands, sometimes physical actions; it could be a lot of different things depending on your system. You'll find these on your wiki, or in the support file server, or (worst case) by talking to your support engineer.
Usually support procedures take the form of a diagnosis and one or more actions. For example, a support procedure might be as simple as, "if Tomcat hangs and won't accept connections, restart Tomcat with /etc/init.d/tomcat5 restart". It can get more complex as well.
What's To Test?
Well, things change. Some of the time you're going to know. A release may contain a feature specifically to address or change a support procedure. For example, if restarting a system involved five manual steps, the software may have been changed to include a "restart all" option that does those steps for you. Great, your support procedure has changed (and it sounds like for the better!).
Other times you may not know. If someone writes code assuming a certain startup flag is first when it used to be second, a support procedure adding the flag will stop working. It's unlikely that anyone will remember to note this change.
So you'd better test your support procedures rather than just assuming they'll work.
Okay, Okay, We'll Get to It
Great! The real urgency here is when you'll be using the procedures. If you're in a state that a support procedure is necessary, then something isn't right on the system. It could be minor or it could be complete inaccessibility of your system, but either way there's something negative occurring. Now is not the time to have something else - your support procedure - fail.
Better to test the procedures before you need them. That way, when you're servicing your system you greatly improve your chances of success. Happier support, happier customers, happier us!