I try to do the following for all the sites I develop. Its most applicable to dynamic sites.. but aspects should be done even on 5 page info sites.
1: Keep development, testing and live sites seperate. Use different folders, and if possible domains.
I have all my development on my "intranet"*. And my live and test (staging) on my hosting package. For clients who have there own hosting I would use a sub-domain of your own site. eg. test-client.yoursite.com. The seperate domains really come into their own if you're using mod_rewrite.
The test (staging) should be on the same system as your live site so that any incompatiblities are spotted now and not when you flick the switch with the CEO watching.
2: Run through an html validator. I do this to catch all the stoopid mistakes that are always made - missing closing tags, spaces before closing angle brackets. Etc. Lots of debate on the use of non-standard compliant html like marginwidth in the body tag. Nether the less its the best way to catch the little html bugs.
3: Get someone to proof read your site ... its amazing how many little typo's and speeling mistakes creep in if you are hand coding or particularly building a dynamic site.
4: Test with every browser and OS that you can get your hands on. As a minimum windows - Netscape 4x, Netscape 6 (or other Gecko Mozilla browser), IE 5x. On linux - Netscape 4.x. Also take a quick peek at it in lynx - gives you a search engine's eye view. I would also include a Mac in this list but I haven't got one.
Test on a 28.8kbps connection ... I try to make sure that there is something displaying withing 8 secs. I'm not so worried that the complete site is there but that the title, logo and introductory information is displaying. The fancy graphics will take longer so include sizes so that the site framework is mapped out as soon as possible. And things don't move around.
5: Usability - some good advice from rogerd above. I would also add that doing this will probably lead to some redesign so do it as early as possible. Its also the most difficult thing to arrange - getting "newbie" testers and paying them will hit the budget. Using friends and family will only work for so long -- they'll get a) annoyed - from personal experience b) good at using your sites and thus no longer count as newbies.
6: If you can, write test cases. Think about all things that can be done with your site and write down scenarios.
So buying item x is a scenario.
Now think of the permutations that can occur. Buying Item X - but gives invalid details .. bad email address, missing credit card info, successful buying of item x.
These can be grouped into three types, Error cases (failing external systems, "wrong"* data from user), Failure cases (eg. credit card declined), Success cases.
I run the success cases on all browsers, on all systems. (well I should do). The error cases are there more to ensure that I've thought about what if .. and fail as gracefully as possible. The failure cases should be handled as well as the success cases.
Well doing all of that is very pedantic but will ensure that blunders like those you mention above won't happen. And if you think thats bad -- I used to write software for telecoms systems ... they have whole departments dedicated to testing every concievable aspect of any new system. It was always better for me to find the blunders than them.
Good luck !
* four PC's in my spare bedroom. 2 linux, 2 win (laptop).
* wrong = valid but incorrect like a wrong email address (typos) rather than junk data (invalid).