Much of what this blog focuses on, besides ISEB and ISTQB certifications, relates to elements of traditional software testing practices. However, testing a website is probably something that falls into the “non-traditional” category and as such warrants a totally separate discussion.
Whereas traditional forms of software testing focus on very cut and dry items, certain aspects of websites are more ambiguous, perhaps even unknown. For instance, there are literally dozens of web browsers in the market, and each one has slightly different ways of manifesting a website’s underlying source code. In other words, your site design might look great in Internet Explorer, but misaligned in Google Chrome for example.
There are plenty of other examples of ambiguous website testing items as well. These include the degree to which the site has been optimized for the search engines, the degree to which the site’s navigation is user-friendly, the speed with which the pages load in the browser, and the security of the information-gathering pages, to name a few.
As you can see, testing a website brings some unique challenges and requires a thoughtful QA process. This is because some of the issues that arise may not be bugs in the traditional sense, but they could still be important to fix nonetheless.
To help, it is wise to define as many of these things as possible when designing the test. For example, the project sponsors may decide that they only care about how the website renders itself in Internet Explorer and Mozilla Firefox, and thus are willing to accept a less-than-perfect rendering in the less-popular browsers.
If you are testing a site and you run into an issue that was not previously defined, technically it may not be a bug but it would still be wise to log it and report it to the project sponsors. At a minimum, if the issue is deemed to be important, it can be addressed in future iterations / releases of the site.
Filed Under: Software Testing