This ad hoc approach to testing means that it is possible to miss [...]]]>

As a website is being built, the step of writing or putting together a test plan is often skipped entirely and testing just ‘begins’. If a test plan is done then it is often completed immediately prior to testing and completed too quickly.

This ad hoc approach to testing means that it is possible to miss large sections of functionality and not be able to fully consider all permutations or variations of events and actions that need to be tested.

For most websites, there is a fairly long list of items that need to be tested as part of any new website development and in order to know what to test, when you tested it and whether those tests passed or failed, it is best to make a proper plan.

We are going to show you how to write a simple and straightforward test plan, which will provide a more systematic method for testing your website but the process outlined below is still essentially a manual one. We are not yet moving into using software tools to help identify and run tests, nor are we covering automated testing here, although I hope to write a post on these aspects in due course.

Writing A Test Plan

A typical test plan should identify all the areas of the website that you need to test before it launches, which you then follow through to conduct your testing, making notes of when you completed the test and adding any bug or issue reports to your bug tracking software along the way.

Start off with getting all the main sections down in a spreadsheet, divided between front end and admin or CMS if the website has one.

Then, start to break each main section down into the constituent parts that you need to test, concentrate on the important parts of the website first such as the home page, which is likely to be one of the most visited pages and the main areas of functionality, which are most likely to be the most used.

For instance, in the case of an ecommerce site, this would include individual tests for items such as adding products to the shopping basket, removing products from the shopping basket, updating the shopping basket quantities, being able to enter the checkout process and completing the checkout process (depending on your website there may be several steps to test within the checkout process).

You should be asking yourself questions for when you start testing the checkout process from the point of view of the user such as:

• Can I complete my order?
• Can I go back and amend my order?
• Do I understand where I am in the checkout process?
• Can I clearly see what I am ordering and how much it will cost, including delivery and taxes?
• Do I get a receipt or email confirmation?

As the owner of the website there will be different questions such as:

• Does the payment processing work correctly?
• What happens if the incorrect card details are entered?
• Does the order confirmation process work correctly?

And so on, when putting a testing plan together you are testing the website from the point of view of the user and also from the point of view of the owner or operator of the website. You may also have specific usability testing lined up but the primary reason for the test plan as far as this blog post is concerned is to test the functional aspects of the website to ensure they work correctly. Does the website do what it says it does? For instance, if the checkout process displays the order details including taxes and delivery then does it show the correct details for both tax and delivery?

Another important area to test is the site search or product search, as this is likely to be used a lot on the website.

Make sure that you test all the forms within the website, such as enquiry forms and newsletter signup forms. Test that the form can only be submitted after the mandatory fields have been completed and that the form is emailed to the correct email address or saved to the database correctly.

Once you go through and think about each section of the website along the lines of the above then you should have compiled a decent list in your spreadsheet of areas and items to test. Add columns for each browser that you need to test each item on, which will be the web browsers that you have agreed to support as part of the project. This would normally cover the major web browsers such as IE6, IE7, IE8, Firefox 3, Chrome and Safari but may include others too depending on the usage of your target market (or existing audience if you have those statistics). There are a range of browser checking tools that can help you with this aspect.

For the admin system or CMS that powers the website, add a row to your test plan for each function. Going back to our ecommerce example, this means that there would be tests for add new product, edit existing product, remove product, view order, edit tax rate, etc. depending on what the system was capable of.

You could break these tests down further to test individual elements of adding a new product. For instance, is there validation present to check that mandatory fields are filled in when adding a product? Does the product image have to be a certain size or dimensions? Does the product title have to be shorter than a certain number of characters? All these items could occupy separate rows in your test plan.

Of course, if you were to break your test plan down to this extent for a large website or CMS then the result will be a long spreadsheet of items to test, which will take a great deal of time to test effectively. You will need to decide whether you have the time available to test in this level of detail or if some areas can be tested more quickly.

A few other items that you may wish to make sure you have as part of every test plan are the following, in no particular order:

• Ensure your HTML and CSS code validates to W3C guidelines
• Test accessibility of the website
• Test the SEO items that you have planned for to make sure they are in place
• Test against the specification for the project that was signed off to ensure that everything has been completed that was agreed
• Test against designs and/or wireframes or prototype html mockups that were completed to make sure the finished website matches the signed off designs or wireframes
• Take into account any changes requested (should be in the form of change control documents)
• Complete any security tests that are required

You may wish to have a look at our list of 10 different forms of website testing to make sure you have covered everything. The list can go on indefinitely, there is always something that can be tested a bit more, but at some point it has to be halted at a relevant point otherwise the testing will never get done.

List or Flow Chart?

Some aspects of the website lend themselves to having a flow chart in place that describes all the permutations or possibilities that need to be tested. This is especially helpful if one action then presents another set of possibilities. When testing without a flow chart it can become extremely difficult to remember which permutations you have tested and which you have not.

Having a flow chart or mindmap worked out that shows you all the possibilities allows you to think more clearly about what you are testing, what you expect the outcome to be and understand what you have tested and what is remaining to test.

Conclusion

If there is too much testing to do for one person then divide it up amongst other people with instructions on what you want testing and what to do with bugs when they are found. Make sure they follow their bit of the test plan and feed back on what they find, handing bugs to you or inputting them into your bug tracking software themselves.

As you test then fill in the test plan to show what you tested and when. If you keep the document client friendly then it can be shown as proof of what testing was completed prior to launch.

Testing is a vital part of any website development and having a decent plan before you start testing saves a great deal of time and effort whilst making sure that all the required testing gets done.

One of the first posts I wrote, which described a typical Web Testing process, mentioned that a bug [...]]]>

An area that has not been looked at in much detail yet on this blog is what software or tools you can use to record and track bugs, issues or defects that you find when testing a website.

One of the first posts I wrote, which described a typical Web Testing process, mentioned that a bug tracking system ‘can be hugely beneficial, as you can set priorities for each bug and then understand how many bugs you have at each priority level. It gives you a much better understanding of how many bugs you have to fix before you can launch and calculate how long you expect that process to take.’

There are a good range of bug tracking applications out there, a lot of them web-based, which are vital when tracking bugs and associated information about each issue. Here we take a look at 4 of the main players in bug tracking software, which are also available in our Testing Tools Directory.

Why Use Bug Tracking Software?

Once you start testing a website you can come up with all sorts of bugs and issues that need addressing. I’m talking a bit more than the odd typo or broken image. Perhaps you find problems with the site search returning strange results or the checkout process not working correctly or there are specific issues in different browsers that work fine in other browsers. There are several different reasons to use an application that tracks bugs and feature requests.

Complicated Bugs

As bugs start to get a little more complex it is important to hand the developer all of the required details about each bug so that he or she can fix it in a reasonable amount of time, without chasing around trying to reproduce it or get a screenshot or URL showing where that bug was found. Bug tracking software gives you a structured format to report bugs so that you include the URL where you found the bug, provide a full description and a screenshot and what browser or operating system you were using. These details will shorten the amount of time that a developer needs in order to squash the bug and improve their productivity. Get more bugs squashed in less time.

Lots of Bugs

Alongside the complicated bugs will still be the relatively quick and simple items to fix such as the odd layout problem, typo, broken image or link, etc. These bugs, whilst they do need to be fixed, are sometimes not as important as other bugs and, when presented in a list or on a spreadsheet, can often be completed ahead of more important items because the developer naturally follows the list through from start to finish. Bug tracking software allows you to prioritise bugs so that developers work on the most critical issues first and leave the less important bugs until later. Rearranging priorities in a list or on a spreadsheet gets too cumbersome when dealing with a large number of bugs but issue tracking software handles this aspect with ease.

Improved Workflow

With bug tracking software you can assign bugs to different developers so everyone knows what they are working on. Once those bugs are completed then the developer assigns them back to you for checking or verifying. If you are happy you can close the bug, if not then reopen it and give it back to the developer. Do this for each bug and you can understand exactly where each bug is in the process, how many are assigned, how many are to be verified, etc. It allows you to have a much better handle on exactly where your web project is at instead of continually poring over your list or spreadsheet and trying to make an educated guess.

This improved workflow eases pressure on you and your developers and improves productivity because developers can just get on with fixing bugs or working on feature requests. It also means that you are not constantly updating lists and spreadsheets with the latest status of all the bugs reported.

Bug Archives

Once bugs are fixed, tested and closed they can be referred to at any time so that you can see when the bug was reported, when it was fixed, who fixed it and what the developer did to fix it (assuming they fill their comments in correctly). This provides an extremely useful archive if you ever need to refer to a particular bug again instead of trying to go back through emails or out of date spreadsheets to find details on that bug or feature request.

Some bug tracking systems allow time tracking so you can see how much time was spent on fixing a bug. Using bug tracking software ensures that developers become more accountable because their comments and times are recorded and can easily be referred to.

Bug Tracking Software

Now that we’ve established what bug tracking software offers and why web project managers and testers should incorporate it as part of most web projects (definitely on all large web projects and probably on most small to medium projects too) let’s have a look at some of the main bug tracking applications currently being used.

My specific experience is with using Bugzilla so let’s start with that one.

Bugzilla

Bugzilla - classic open source bug tracking application

Bugzilla was originally released by Netscape in 1998 and so has been around for a long while now. This open source software is one of the first bug tracking applications that spring to mind and, although it takes some setting up and the interface is a bit tricky to use, it has everything you need to record and track bugs effectively.

It is possible to sidestep the web interface by using a desktop client that synchronizes with the central bugzilla software. My specific experience with bugzilla was using the Deskzilla client on a Mac, which worked well.

As Bugzilla is open source then it is free to use although it needs to be installed and set up on a server in order to be ready to use.

Unfuddle

Unfuddle - web-based bug tracking software

Unfuddle is a hosted bug tracking application that also includes Git hosting and Subversion hosting allowing you to create your own secure code repositories. There are also some project management tools included such as tracking your project against specific milestones and time tracking is available in the more expensive corporate and enterprise packages.

Bugs, issues and feature requests are raised as tickets in the Unfuddle system and each ticket includes workflow management and an audit trail so you can keep track of who made changes to a ticket and when these changes were made.

If you need the code repositories and project tracking functionality along with a straightforward bug tracking system then Unfuddle could be the answer. There is a free package available that includes 1 project for 2 users. After that prices start at $9 per month.

Trac

Trac - open source issue tracking software with project management tools and a wiki

Trac is also open source software that combines an issue tracking system with a wiki and project management features such as milestones and being able to document the roadmap for a web project or software development. Trac can also serve as a web interface for version control systems giving you a usable front-end for Subversion or Git.

Tracking progress of individual bugs, issues or feature requests is straightforward with each one having its own numbered ticket with the ability to filter tickets by severity, project component, version or owner. Keeping on top of progress is also easy with the ability to set milestones and being able to see how far you are from reaching each milestone.

Trac has a good set of features and is a lightweight and flexible system that should be very useful for most web development projects. It runs on most operating systems but does require some setting up and this is perhaps its biggest downside that I can see if you want to start tracking bugs straightaway.

FogBugz

FogBugz - web-based or installed bug tracking software with large feature set

FogBugz is available as a hosted application, called FogBugz on demand, or as installed software on either Windows, Mac or Unix operating systems.

There are several parts to FogBugz, the issue tracking section makes it very easy to report bugs and you can even create bugs via email or create bugs quickly without having to fill in everything so you can get the bug into the system. Whilst I think this is a good feature you do need to make sure you go back and complete all the details before you assign the bug to a developer to work on. Everything is saved in a complete case history for future reference.

But issue tracking is not all that Fogbugz does, there is a project planning section where you can outline tasks, break larger tasks into subtasks, enter estimates and set milestones. Fogbugz also has something called Evidence-Based Scheduling, which looks at what tasks are being estimated and how long they actually took to complete and then plot a probability curve to work out whether a milestone can be hit or not. The FogBugz Wiki allows you to keep all project documentation in one place and there are also a whole load of plugins available to extend the functionality plus FogBugz can integrate with another piece of software from the same company (Fog Creek Software) called Kiln, which is a version control system.

FogBugz is the most expensive of the bug tracking software applications featured here with prices starting at $25 per user per month for FogBugz on demand or $999 for 5 users for the installed version of the software.

Conclusion

Whichever of the above applications you use, as long as you use one of them and get your workflow organised in terms of how you report, record and assign bugs then you will find that it becomes a breeze to keep track of exactly where you are at in your website testing. You won’t miss any issues (as long as they are reported and entered into the bug tracker), you can prioritise showstoppers or critical bugs easily to fix those first and archive completed bugs for future reference.

If I had to pick one of the applications above then I would go for either Unfuddle or FogBugz (on demand) because I like web-based applications as there is nothing really to set up or install. Both of these have a trial although both cost money whereas Bugzilla and Trac are free but require time installing and setting them up on a server.

FogBugz has the better overall feature set and I am intrigued as to how the Evidence-Based Scheduling works, as I have not come across that before. But it terms of a cheap, easy to use, bug tracking system that is ready to go and will do the job, I would pick Unfuddle with the caveat of going for FogBugz if I had a bigger team (and didn’t mind paying more money).

At the moment that testing subject of choice [...]]]>

When I’m reading blog posts, news articles or Twitter discussions concerning the testing of websites, the article or discussion in question actually relate to a single aspect of testing and gives the impression that there is only one form of website testing that we should be concerned with.

At the moment that testing subject of choice is known as Conversion Rate Testing, or sometimes called CRO (Conversion Rate Optimisation). This would normally mean that the tests being carried out are Split Tests or Multivariate Tests, using software such as Google Weboptimizer.

Don’t get me wrong, conversion rate testing is really important and can greatly increase the number of conversions on a particular page, which can raise sales, enquiries, profits or whatever aspect of conversion you are trying to improve.

But there are other forms of testing websites, quite a few in fact, and some that are quite basic that get overlooked. I wanted to give a brief description for each type of testing to help you understand all the areas that can (and should) be tested when launching a new website, rolling out a set of updates or at least checking on a regular basis.

Different Forms of Testing

Functional testing

This form of testing aims to ensure that the website works correctly or as it was intended to. You click on a link, does the website display the correct page? You complete a search, does the website return the correct search results? You add a product to the basket, does the website add the correct product to the basket? Functional testing is going through the entire website, including content management system or admin area, to make sure that each function within the website is performing as it should be.

Browser compatibility testing

Different web browsers display web pages differently from each other. This is one of the least helpful aspects of the Internet and browser compatibility testing or browser checking involves testing the website on each of the major browsers (or each browser that you have decided to support), which generally includes IE6, IE7, IE8, Firefox 3, Chrome, Safari 3 and Safari 4 on both PCs and Macs. You could possibly include Opera 9 and Opera 10 in that list in addition to testing your website on Linux as well as Windows and OSX. You could also check your analytics to see which browsers are most commonly visiting your site. There are several decent browser checking tools listed in our testing tools directory.

Usability testing

Usability testing assumes that your website works correctly and displays in each major browser correctly. However, a website that functions correctly is not necessarily a usable website for your target audience. Usability testing enables you to show your website to a group of users, ask them to perform certain actions and see how they accomplish those tasks. There are many reasonably priced usability testing tools on the market that have made this type of testing much more straightforward, many of which are listed in our testing tools directory. It is possible to gain great insight into how people actually use your website and a lot of the experts agree that you can pick up most usability issues when testing with only 5 users.

Accessibility testing

Accessibility testing is extremely important to make sure that your website complies with best practice and accessibility guidelines plus legislation surrounding accessible websites, which is in force in both the US and UK. In the US there is Section 508, which is part of the Rehabilitation Act and in the UK we have the Disability Discrimination Act or DDA. A fully accessible website not only benefits those users that would otherwise have difficulty using your website but search engines will also be able to navigate and understand your content more easily, thereby helping your search engine rankings. To help you test your website’s accessibility there are some accessibility testing tools available in our directory although manual testing is still recommended.

Performance testing

Performance testing is an area that has always been important but possibly even more so now that Google is starting to incorporate the performance of a website into its ranking algorithms. There used to be an 8 second rule, which believed that a user will wait no longer than 8 seconds for a page to download before they click back and try another website. That rule is a long way out of date, it is now no more than 1 or 2 seconds. Performance testing can show you when your website is slowing down, which pages are taking time to load and what element of the page is causing the problem. Performance testing tools are covered in our testing tools directory.

Stress or load testing

There is a difference between stress and load testing in that stress testing concerns itself with trying to break the system you are testing whilst load testing aims to find out how much volume you can put through the system. Both of these forms of testing are generally for larger websites and web applications. A range of stress and load testing tools can be found in our testing tools directory.

Site monitoring

A really simple test that you can put in place is to automatically monitor your website to check for downtime or outages. Nobody likes a website to be down including users and search engines. Regular downtime will lower confidence in your website and they could be affecting your traffic levels and therefore sales or enquiries without you knowing. A selection of site monitoring tools can be found in our testing tools directory.

Conversion rate testing

The current favourite form of testing, and an important one too. Conversion rate testing or optimisation can greatly improve the amount of visitors your website converts into enquiries and/or sales. If your SEO brings in 100 visitors a day and your site currently converts 5 of those into becoming customers then, with successful conversion rate testing, you could convert more visitors into customers and make more sales. Conversion rate testing normally takes the form of running split or multivariate tests on your website, many of which are listed in our testing tools directory.

Security testing

Websites can have security holes that could be extremely damaging for your business if they were to be found and exploited. Security testing aims to find where those security holes exist so that you can do something about them.

Spelling and Grammar checking

It is always useful to fully read through all text on the website to ensure there are no typos or grammar mistakes. You will also spot how you can improve the readability of text and other areas that perhaps need some attention. Also make sure you read through all messages that appear when signing up for a newsletter, adding products to a basket, or registering including any error messages. Simple changes to the wording of an error message into a nicely worded error message can make a big difference.

So there you have it, website testing can take on many forms and all of them should be completed to a greater or lesser degree. At least by completing each type of testing you can be aware of any issues or areas for improvement so then properly plan out what action you are going to take and when. Good luck with whatever testing you complete.

The Opera 10 web browser was released as a final version on September 1st after being in beta for a fair few months. It was set to revolutionise web browsing when it was first announced but are your web sites compatible with [...]]]>

Sydney Opera House - took nearly as long to finish as Opera 10

The Opera 10 web browser was released as a final version on September 1st after being in beta for a fair few months. It was set to revolutionise web browsing when it was first announced but are your web sites compatible with Opera 10 and is it worth worrying about?

So now that Opera 10 is out of beta and launched on an unsuspecting public, I decided to install the newly released web browser and put it through its paces with a few web sites to see how they display and to make sure they work correctly.

From checking over several web sites that I am familiar with and had a hand in project managing and testing when they were launched, including a couple of decent sized gaming web sites, I can safely say that Opera 10 does a pretty good job of displaying those sites as they were intended. I could only find one or two very minor layout issues from the brief checking that I completed although overall I still preferred using Firefox for browsing, as Opera 10 did not load in the pages fully on some occasions. This could be my Internet connection but I was using Firefox to load in exactly the same page just a second or 2 after Opera so I believe it is more likely to be Opera.

Presto 2.2 Rendering Engine

Opera 10 uses the company’s own Presto 2.2 rendering engine to produce pages and display them on screen and so separate browser compatibility testing just for Opera should be considered just in case Opera decides to display an element or part of a layout in a different way to other browsers.

As I mentioned above, from the checks that I have completed today I am not massively worried about going through all of the sites I have worked on to ensure that they display and work correctly (although that is always a good idea if you have the time) but should Opera 10 be added to the standard list of major web browsers that I test web sites with?

Opera 10 Usage

From reviewing the browser usage statistics at w3schools.com, Opera shows as being used by 2.1% of Internet users. Deliving into this a bit deeper we can see that 2.0% are currently using Opera 9.5 and so could be expected to upgrade to Opera 10 in the near future.

So the usage figures are very low, even taking into account Opera 9.5 users that will probably upgrade at some point. And there are some features worth upgrading for in terms of Opera Turbo, which compresses pages to speed up browsing when on slower connections, revised tabs area and an improved Speed Dial page.

Opera For Mobile Users

What we should also remember is that Opera is used as the main web browser for many smartphones, PDAs and other mobile devices, including netbooks. The advent of Opera Turbo, which has also found its way into the company’s mobile version means that devices that connect to the Internet on 3G or similar connections will often use Opera as their preferred browser.

If your web site is going to be frequented by mobile users then I would strongly recommend that you make sure you test thoroughly in Opera 10 and its mobile equivalent version (version 9.7 is currently in beta). For those looking for all round browser compatibility then some testing in Opera 10 would certainly be recommended but, as is often the case, if you are seriously stuck for time in your testing plan then Opera will probably be the first of the ‘major’ browsers that you can safely not worry too much about. There will undoubtedly be more issues to discover in the IE’s (6, 7 and eight) and I would continue to concentrate on those browsers along with Firefox and Safari/Chrome.

Browser Compatibility Tools

For those of you wishing to test in Opera 10 then you can download the browser for Windows, Mac OS X and Linux here and run it alongside other browsers that you may have installed. So it is easy to flick between Opera and Firefox or IE8 when checking individual web pages over.

In terms of the browser compatibility testing tools that are out there and shown on our testing tools page, the following are showing as supporting Opera 10.

• BrowserShots – showing as supporting Opera 10
• BrowserCam - showing as only supporting up to version 9.62
• Litmus - showing as supporting Opera 10
• Xenocode (or Spoon as it is now known) – showing as support Opera 10
• CrossBrowserTesting – not showing as supporting Opera 10 yet
• BrowsrCamp - showing as only supporting up to version 9.61

Further Reading For Opera 10

• IT Pro Review of Opera 10
• ReadWriteWeb’s mini review of Opera 10
• makeuseof.com – 6 Unique Features That Make Opera 10 Stand Out

Photo credit -: pranav :-

Internet Explorer 6 has long been the bane of web developers and web testers lives. Is it time to stop supporting IE6 users and pouring time and effort into this antiquated browser or should we, as decent web professionals, keep these users in the web ways they are accustomed to.

The [...]]]>

Should we stop supporting IE6?

Internet Explorer 6 has long been the bane of web developers and web testers lives. Is it time to stop supporting IE6 users and pouring time and effort into this antiquated browser or should we, as decent web professionals, keep these users in the web ways they are accustomed to.

The most common problems that web designers and developers face with IE6 are CSS styling and layout bugs where the fixes required are often reached after several hours of trial and error. The IE6 PNG fix has gained prominence as being one of the more famous bug fixes around. More experienced developers will be able to implement these fixes more quickly but there can still be considerable effort needed to iron out these frustrating bugs.

When working on the development of a web site I find that there is always an aspect to the project that is related to IE6 testing and bug fixing, either the site in development is regularly checked as the build progresses or there is a big effort at the end to fully test the completed web site for IE6 oddities.

So is this additional effort warranted for one browser or is the IE6 issue hyped and not really that much of a problem at all, just something that we are all capable of dealing with just like any other browser?

Well, there are a lot of people who think that we should stop supporting IE6 altogether. A few of the more well known campaigns are Stop IE6 and Save The Developers who believe that users should boycott IE6 and move to newer and better web browsers.

This has caused a lot of debate amongst web developers for the best part of 18 months or longer. Whilst the numbers of IE6 users do appear to be finally coming down – July 2009 shows IE6 accounts for 14.4% of browser market share, down from 32% in January 2008, according to w3schools.com, which means there is still a significant number of them.

And that’s the problem, IE6 is, like it or not, still a major browser, even after all these years. It is in fact still the third most popular browser after Firefox 3 and IE7. Internet Explorer 6 was released in August 2001 and so has been around for exactly 8 years. In fact, IE6’s eighth anniversary was on August 27th, as Wikipedia has told me today.

So why are there so many people still using IE6 as their web browser?

Is the continued use of IE6 because that is the browser that was pre-installed when the computer was originally purchased and the user has never upgraded? Is it that simple?

It seems completely reasonable that there are thousands, if not millions of Internet users that purchased a computer for home use back when IE6 was practically the only web browser around (or more to the point was already installed on the computer they bought) and have continued to use it to surf the web completely oblivious to the need to upgrade. They simply have no motivation or desire or perhaps even the understanding required to upgrade their web browser. These users could easily still be running Word 97 and playing solitaire on a 15 inch CRT monitor with a resolution of 800 x 600 for all I know.

That may be unfair but in general terms we need to test most web sites for the lowest common denominator and, for the moment, that still includes IE6.

Despite all the campaigns trying to get users to upgrade their browsers or persuading developers to stop supporting IE6 when building web sites IE6 may only finally drop to a minor browser level after everybody has upgraded their computers rather than just their browsers.

So perhaps the campaigns should be about getting users to buy a new computer rather than using the old PC that they purchased 5 or 6 years ago.

But until the number of IE6 users drops to levels that are not as concerning do we continue to develop web sites and web applications with IE6 in mind, spending considerable resources in the process and huge amounts of frustration when it comes to testing and putting fixes in place when other browsers display the web sites we build pretty much as intended.

Or do we simply check for the browser version that they are using and, if it is IE6, display a message telling them they their browser is not supported, they cannot enter the web site and provide them with a link to our favourite alternative?

I have seen several web sites do something like this or sometimes they let the IE6 user have access to the web site with the proviso that there may be problems lying in wait.

The latter option is not a solution in my mind, akin to a doorman saying ’sorry mate, you’re not coming in’ when you try to walk into a shop. Perhaps the statistics for your own web site show IE6 users as being a lot less than 14.4% at present and your decision is to stop supporting them. Well, that of course is up to you but I think I will be continuing to test all web sites in IE6 for the foreseeable future, until such time as new computers are purchased or users finally see sense and upgrade to a more modern browser.

What do you think about continuing to support IE6? I would be interested to hear your views.

Photo courtesy of Flickr and z6p6tist6.