CHECKLIST FOR TESTING:

BROWSER (IE) SIMULATION: in IE, choose Tools...Developer Tools, then choose various older versions of Internet Explorer under "Browser Mode" and "Document Mode". If the site isn't behaving, try to get it working in all IE versions.

CELL PHONE / SMART PHONE FRIENDLY: is the site usable on a smart phone? Is the font legible, are the menus usable?

CHANGE CODE FROM TEST MODE TO LIVE MODE: for example, if your form processing PHP script is supposed to send an email to the client, but in test mode you have the emails being sent to you, fix this!

COMMENTS: make sure you comments are where, and only where you want them.

COMMENTS: make sure you don't have any dangling opening or closing comments. For example if you removed a '/*' but forgot to remove the corresponding '*/', this will break your web page.

COMPATIBILITY MODE DRAGGING YOU DOWN?: if your client is paying you minimum wage, and therefore you and they agreed that you shouldn't double your billable hours by attempting to fix the inevitable problems that occur in Internet Explorer's lovely "Compatibility Mode", there is a way to prevent the user from using the site in Compatibility Mode -- add the following META tag to each page:<meta http-equiv="X-UA-Compatible" content="IE=7,IE=8,IE=9" >The markup validation service at validator.w3.org flags this meta tag as an error, it says "Bad value X-UA-Compatible for attribute http-equiv on element meta." I haven't tried it yet, but I read that a workaround is to set this compatibility attribute using PHP:header('X-UA-Compatible: IE=7,IE=8,IE=9');And the web page will still work -- having compatibility mode turned off is well worth having the validator service claim that the meta tag is an "error" when it is not an error. Try it and see -- you'll be glad you did!

UPDATE 11/22/2012: according to website redmine.org/issues/10128, the following is the correct format to use:<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />

Maybe it tries IE9 format first, and if your browser is IE9 will use it, then if IE9 isn't available on your computer, it will try IE8 format, etc, hence the importance of putting IE9 first.

According to website expression.microsoft.com/en-us/dd835379.aspx, <meta http-equiv="X-UA-Compatible" content="edge" /> will render in the most recent version of IE that's available, so I don't see why you also need to mention IE=9; IE=8; IE=7; but oh well. And should semicolons be used, or commas?

UPDATE 12/9/2012: There's a jQuery gallery here that wasn't working correctly in IE9 unless I turned on Compatibility View. Ideally, I'll be able to fix the code so that it works with Compatibility View turned off, but in the meantime, I added the following Meta tag to force IE to use Compatibility View:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

DIV NAMES: If a DIV is not working, does the DIV name in the HTML code match the DIV name in the CSS, or did you change the DIV name in the CSS while forgetting to change the DIV name in the HTML code?

DOCTYPE: make sure there is nothing (not even comments) before your DOCTYPE statement. I recommend using an HTML 5 DOCTYPE: <!DOCTYPE html>

IMAGE NAMES CORRECT?: I had a background image 'speedvids_logo.gif' that wasn't appearing. This is because the image file name is actually logo_speedvids.gif, not speedvids_logo.gif, so the code wasn't finding the image file, because an image with that filename does not exist. Maybe images should have natural sounding names like "speedvids logo", and not nerdy names like "logo speedvids" meant only for better alphabetic sorting. Instead, make a "logos" subfolder under the images folder, that way the logos can be together, and also have simple, non-confusing filenames. Some common mix-ups: calling a lime green image 'lime_background.png', when the image name was actually 'green_background.png'. Calling something 'temp' when the name was actually 'test'.

IMAGE NAMES TOO GENERIC, HENCE CONFUSING AND CAUSING PROBLEMS?:
I named four button image names 'button1.png', 'button2.png', 'button3.png', 'button4.png'. The slideshow wasn't working correctly, turns out the cause of the problem was that I thought 'button2' was for the 'next slide' button when in fact it was for the 'play' button. So to fix, renamed the image files 'next.png', 'play.png', 'stop.png', and 'next.png', so that it was obvious how which files should be used where in the HTML and jQuery code.

JAVASCRIPT DISABLED: some users intentionally have JavaScript disabled, for various reasons such as to reduce the chance of being attacked by malware. Your website should take this into account, by loading in alternative content if your Flash or jQuery widget can't run due to Javascript being disabled. And if you want, display a message that they have Javascript disabled, which makes parts of your site unavailable. That way, if they have Javascript disabled by accident, they may decide to go ahead and enable it.

NOTHING HAPPENS WHEN YOU MAKE CHANGES TO CODE: If you keep making changes to code and they aren't showing up on the web page: (1) are you viewing the correct version of the page in your browser? Perhaps your current test page is up to test5.htm, but you're still looking at test4.htm in your browser (2) if you're looking at a published page (not a local one), did you upload the changes with FTP? (3) If you want to look at a local page, are you mistakenly looking at the live site instead?