Forum Moderators: phranque
Before making the site live we are going to run tests on it, speed, navigation and general bug testing. What I would like to know is does anyone here have any tips on how best to test a site before making it live? In my experience this is something that is often taken quite lightly and I have seen some sites go live which then have to have major alterations made due to bugs. So, how does everyone check their sites before publishing them?
Thanks..
One thing I like to do is use Xenu Link Sleuth on a new site both to check links and also check page titles. I often find a page or two that I failed to optimize after using a template to generate the original page - the template title sticks out in the Xenu site map. As a plus, you can use the site map Xenu generates as a spider-guide.
Also, during testing/startup, pay close attention to your logs. You may spot errors or unexpected visitor behavior.
===
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 !
Gethan
* 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).
[website-wisdom.com...]
Gethan's point about keeping development/testing/live sites separate is well taken. I run retail site, hosted in another state, that's built on Site Server Commerce and SQL - I have a testing server with everything here so I can design/test locally before uploading to the live site. EXTREMELY helpful. I've done the design then upload then test thing and it's a real pain to catch errors before an actual customer.
I use Visio to create a full site map,and then validate each page manually.
From a usabilty side if you can line up 5-10 people with varying levels of internet profociency and interest in the sites subject matter and give them set them 10 or so tasks to perform , the feedback from this is invaluable. A proffessional usability audit can cost thousnds of Euros, but if you get friends, family and colleagues involved it can be done for the price of a meal ;) and is money well spent as long as you pay attention to their findings.
I also use a hueristic usability guide from the start and then go back and check all at the manual validation stage.
I highly recommend, depending on the size of the site and number of possible users/visitors, to look into other means of testing(load, stress and detailed functional testing).
url snipped - see profile
If you have any questions, feel free to email me snip - see profile
Thanks and good luck!
Artem
(edited by: engine at 11:07 pm (utc) on Jan. 4, 2002)