One thing that James Bach has is a 31 letter mnemonic that helps him tackle a testing problem. In a previous version of the Rapid Software Testing slides he had it on one page but has now broken it up over a couple. Its actually kinda creepy when you as him what the 3rd C means and he can tell you immediately that it is Compatibility. During this section of his course, he recommends you not use his, but create your own as it will have more meaning to you. So here is mine for the broad categories of testing (in order) that I do when approaching a new testing task.

    <font size="+2">S</font>ecurity
    <font size="+2">L</font>anguages
Requ<font size="+2">I</font>rements
    <font size="+2">M</font>easurement
    <font size="+2">E</font>xisting functionality

The rationale for that order is this. If there is a security problem, too it is often not an easy fix but means redesigning an entire section of code to be secure. Same with supporting other languages that english (i18n, l10); having been through the process of grafting that functionality onto existing systems I can guarentee that you are going to have to retest everything after it so find problems there first. Once any fundamental security or language support issues have been identified and addressed, I then dive headlong into the requirements (both explicit and implicit). After satisfied that the requirments have been met I move onto the types of tests that measure things, be it performance, stress or load testing. Sure, issues here could mean a design change, but hopefully anything that severe was found during the requirements verification section under the guise of an implicit requirements that the system not be ‘dog slow’. Finally, I look at existing functionality (regression test) as there should be no more changes to the underlying design of the code.

And yes, it did take longer to decide on phrases that spelled a word than the order the testing happens.