Here you can find information about the website testing techniques. So your website looks nice colours, images and interesting content. It’s ready for public viewing. Well, most of the readers were asking for long lists of questions on Website Testing Checklist. So in its place of answering individual I think piece of writing on Complete Checklist for Website Testing.
This does not mean that you follow this Website testing list for all types of Website. This is the kind of checklist to remember while testing your website. The chance of Success (or failure) is totally depends on the particular situation.
The Website Testing Checklist
1. Validation
Validate the HTML
The first step of checking a website is you have valid HTML or XHTML. HTML validation is a process of checking your web page a proper standard published by the World Wide Web Consortium (W3C) for HTML and XML. This can be done with a validator such as the W3C validator or WDG validator.
HTML validation is a necessary step towards ensuring the technical quality of web pages. Your own browser may ignore certain errors, but there is an important risk that markup errors will result in display problems in some browser or other.
Validate the CSS
CSS can be validated with for example the W3C CSS validator. The considerations here are much the same as HTML validation, except that there shouldn’t be any need for CSS syntax errors. It may sometimes be necessary to use something non-standard to get Internet Explorer to work, but such rules can be placed in a separate CSS file and hidden in an Internet Explorer conditional comment, where they won’t bother other browsers or a validator.
Check broken links
Definitely you don’t want broken links on your site. There are various tools available to help find these, such as the Xenulink this is the convenient for checking a whole site.
Also Read : Top 5 Automated Web Based Testing Tool’s
2. Accessibility
A web page is accessible under a wide range of browsing conditions. However accessibility is often used in the narrower sense I give below, and I couldn’t think of a better heading for this section. So I’ve left it as it is.
Test accessibility
This is mainly important for handicapped users, but also relevant for e.g. people who use a text-only browser, or disable images, because of a slow connection. Many aspects of the guidelines require human judgement to say whether a page is accessible or not – for example whether HTML Heading tags are used correctly. And even when the guidelines are unmistakable, you don’t need to follow them slavishly. For example the absence of a caption on a table is unimportant if the previous paragraph explained what the table is about. Nonetheless it is well worth running a few pages through a checker such as Bobby or Accessibility Valet in order to familiarise yourself with the issues involved. You can then make the necessary improvements.
View in text browser
It is also worth running pages through a text-only browser, or text-browser emulator to see what e.g. a blind person using a text-to-speech converter will encounter. It will help you pick up on badly-chosen or missing ALT texts for example. Also shows you the site pretty much as a search engine will see it.
3. Browser independence
Your site may be viewed in a large variety of situations: different browsers, different operating systems, different features enabled or disabled. It is important that your site stands up well in these different situations. The first point of attention here is validation – described separately above. Then there are the following points.
Cross browser checks
Almost all web developers are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be:
- Chrome, Firefox and Safari – as these seem to have the best standards compliance;
- Internet Explorer for Windows – currently the most widely used browser;
- Opera – growing in popularity due to its speed and pretty good standards compliance.
Until recently I also recommended checking as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now very small (well under 1% and decreasing); it’s a marginal decision as to whether it can safely be ignored. See my page on Netscape 4 support for further thoughts on the subject.
4. Check printed pages
Print some of the pages on a normal printer (i.e. with a paper size of A4, quarto or letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably can’t achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page.
You should also consider using CSS to adjust the appearance of the page when printed. For example you could suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the “@media print” or “@import print” CSS features.
Some sites provide separate “printer friendly” versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldn’t usually be needed.
