Browser

Testing Web applications with multiple browsers

One of the messier aspects of delivering Web applications to the Internet is comprehensive testing to ensure a consistent user experience with different browsers. Given the wealth of browsers and versions along with operating systems, this is easier said than done. Here's a look at various avenues for proper application testing.

One of the messier aspects of delivering Web applications to the Internet is comprehensive testing to ensure a consistent user experience with different browsers. Given the wealth of browsers and versions along with operating systems, this is easier said than done. Here's a look at various avenues for proper application testing.

Who will use it?

A key ingredient when approaching the testing phase of a Web application is deciding what browser platforms will be used to access it -- or, more appropriately, what browser platforms will be supported. With intranet applications, the browser is more easily controlled, but the public Internet is wide open, as users are free to use what they want.

A quick glance at browser statistics for December 2007 on TheCounter shows Internet Explorer with a commanding lead in browser usage (version 6.x at 44% and version 7.x with a 35% share) and Firefox and Safari with smaller shares. You may examine such statistics and decide to test an application with the top four browsers, or the client may decide what browsers will be supported. (It is worth noting that the growth in the use of handheld devices like cell phones and PDAs means you may need to test these as well -- depending upon the application.) Once you decide what browsers are supported, you need to decide how to actually test with these browsers.

Testing platforms

You need to decide how to properly test with a set of browsers. The simplest, and most costly, solution is to set up test machines with each browser installed. Or, you may choose to install each browser on the same machine; however, this can get hairy when dealing with multiple versions of the same browser platform (like Internet Explorer 6.x and 7.x). One issue with using multiple browser versions is actually getting copies of older browsers. A great resource for locating older browsers is evolt.org.

One browser you may not want to ignore is the text-based Lynx browser, which is still available. It is good for testing how a site looks to nongraphical browsers like search engines. Also, it can help with testing accessibility issues because it shows how the site appears when presented as text -- with this text processed by screen readers and so forth.

Along with using multiple browser versions is testing with the numerous operating systems in use today. You may test Internet Explorer with Windows Vista, Windows XP, and Windows 2000, while using Safari with the various OS X versions like Leopard, Tiger, and Panther. Also, you may test Firefox on these platforms along with Linux.

It's costly to set up individual computers for each browser and operating system configuration. Dual booting and virtualization provide alternatives that allow you to consolidate testing environments and reduce costs. Dual booting can be time consuming because you have to reboot every time you switch to a different operating system. Virtualization allows you to run multiple virtual machines with heterogeneous operating systems at the same time on the same physical machine. You can switch to the different machines without any lag time with rebooting. Some popular virtualization platforms are VMware and Virtual PC.

You can get the most control by conducting all application testing with multiple platforms in-house, but this may be out of the realm of possibility for smaller organizations. Smaller shops may turn to a set of users or use third-party services.

Another path

I have worked on numerous projects where an established set of users outside of the organization are tapped for application testing. In addition to using various platforms, it also provides the opportunity for real-world testing where users have their own Internet connections, and testing does not rely on high-speed corporate connections.

These users can provide valuable feedback on application behavior and performance. In addition, organizations often use this type of setup even if testing is conducted in-house. These users may be viewed as beta testers where they offer a second wave of testing to ensure proper functionality in the real world.

Another path that may be followed is using a third-party service to test a Web application via multiple browser platforms. You could choose an offshore company to test with various platforms or use a free service like Browsershots or a paid service like BrowserCam.

The mobile world

The boom in mobile device usage means this ever-expanding user community should not be ignored. Like personal computers, you can assemble a group of mobile devices to use for testing, or you can use third-party services and products to assist with mobile testing. A great resource is the DotMobi Virtual Developer Lab, which provides access to hundreds of mobile devices for testing.

Make sure it works

While most developers think an application is ready once their work is done, you still need to conduct extensive testing to ensure the product delivered actually meets project expectations and behaves consistently within the target set of browsers. There are many ways to go when testing with multiple browsers as you may choose to set up multiple machines, use virtualization, or even go with a third-party service or organization.

The key issue is to test an application so it functions properly within supported browsers. How do you test your Web applications? Do you get users involved or keep it in-house? Share your thoughts and experience with the Web Developer community.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Development Zone newsletter, delivered each Tuesday. Automatically subscribe today!

About

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

18 comments
jond4u
jond4u

If you want to know whether your pages are clean code quickly, you can go to validator.w3.org. It will inform you how many coding errors and proprietary statements there are on a page. EMBED, for example shows up as an error, as do the parameters of that statement, for a page that declares itself to be HTML 4.01 transitional, or XHTML 1.0 transitional.

jond4u
jond4u

In my experience, it is also necessary to view or listen to content in different media players, and offer content that multiple platforms can use. People often want a player for MP3s or a window for video on their pages, and this requires not only multiple browser testing, but also testing with different media players and different versions of each player. I avoid encoding content using CODECs for the latest players in favor of offering content more users can access. That is - saving a QuickTime movie in 6.0 format gives you access to users still running Windows 98 or 2K, who would otherwise be unable to view it. BTW - Apple also was proactive by making JavaScript files and instructions available to developers, when Microsoft elected to block 3rd party active content by default in IE7. Though MS will be changing this in an upcoming release of their browser, many developers have already been forced to re-code their pages.

jond4u
jond4u

I agree with jspurbeck and rccprof that W3C compliant design is the way to go. I also echo Jaqui's sentiment that if more designers wrote to standards, browser builders would be forced to support standards better. When you blend in the piece of full multimedia support, things get interesting and a little dicey, but this is precisely the functionality many of my clients require and demand. Though the EMBED statement is not part of the HTML 4 spec, it was necessary to include it with the OBJECT declaration for some browsers to see your embedded player. Now, for IE7 to work, you need to call the media indirectly using JavaScript. I think it's great that Adobe has crafted an all-purpose solution, which is available for free on the web, in the form of JavaScript includes and instructions on how to code the HTML. Still; it would be totally unnecessary if Microsoft hadn't thrown a monkey wrench into the works. As it stands; developers need to code for three possible methods, to insure content is accessible from all browsers. They need to have a SCRIPT that passes variables and calls all MM content externally, and a NOSCRIPT section that has an EMBED wrapped in an OBJECT declaration. Seems pretty convoluted!

Jaqui
Jaqui

a good idea, but they do seem to have a slight problem with their queue processing. They allot 30 minutes for the screencaps, and have a default of 31 browser version on linux, windows and macos. I checked my own site with it. * Submitted 1 hour, 25 minutes ago * Expires in 10 minutes * Queue estimate: 3 minutes (Details) * 31 browsers selected, 30 uploaded they do allow for extending the life of the request, to the 30 minute mark, but they should have the default display results in the default time. nice extra is that you can download an archive with the screenshots, so you can have the visual record of how it worked.

rccprof
rccprof

As a previous post suggested (and this article completely ignored), it is important to develop your app to the W3C standards. In terms of testing, this means you should test your application in the most standards compliant browser you can first, such as the most recent version of Firefox (Win or Mac). Only when it is working there should you bother to test in any IE version (for market share considerations). With IE, start with the most recent version (IE7 now) and work your way down (IE6, etc.) as needed. There are standard workarounds for most most IE bugs (for example CSS implementation bugs). Other browsers or platforms that are also a concern should be tested as well. With this approach, over time as browsers become more standards compliant your app will only get better and better.

TJ111
TJ111

Multiple IE's. Install IE7 on your machine, so that way it's your default IE browser. Then go download multiple IE's, which will allow you to have IE3, 4, 5, 5.5, 6 as standalone web browsers. Get Opera and Safari for windows, and you have all the browser you need for testing your apps. Also, download Firefox 1.5 and 3 beta 2. Then, for FF2 and 3, go to the properties and add the following switch to the target attribute: "-no-remote". The full target will look something like: "C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote Additionally, you can create a test profile to test all firefox browsers with all the default settings, add the -p flag along with a profile to use. "C:\Program Files\Mozilla Firefox\firefox.exe" -p test -no-remote With all that done you can run Internet Explorer 3,4,5,5.5,6,7; Firefox 1.5,2,3 , Opera, and Safari all simultaneously for testing your applications. Takes 10 minutes to set up and makes development and testing easy.

Neon Samurai
Neon Samurai

There was a VMware appliance with a bunch of different browsers wrapped up inside it for testing websites. I passed it a while back but I hope it is still available and up to date.

jspurbeck
jspurbeck

Write to the w3c specification, encapusulate all dom-level calls. Provide intelligent sensors (window.attachEvent) to determine if the browser is using the MSIE model. If so, create wrapper functions to encapsulate the proper handling of the deviations. Do not use "browser detects" throughout your application. When web apps are developed to web standards, AND, the browser vendors support those standards, this issue will become mute. We are almost there. Good Luck

ahnc
ahnc

There's an installer that will install multiple versions of IE at http://tredosoft.com/Multiple_IE. Be careful, it's not completely stable so you may experience a few bugs (in addition to the ones already in IE).

Jaqui
Jaqui

from the recent version of a palm device I looked at, the mobile devices also present the site same way that lynx does. It is a very simple matter to use lynx to see what both visually impaired viewers and mobile users will see. A good thing to note when designing for both visually impaired and mobile users and testing with lynx: Lynx does NOT support images at all. Lynx does NOT support tables. Lynx does NOT support frames. Lynx does NOT support javascript. Lynx ignores css and divs in xhtml / xml code, it does present the basic html code embedded. [ exactly as mobile systems browser ] edit to add: Lynx does NOT support Flash. Lynx Does NOT support PDF. Lynx does NOT support sounds. and for whatever it's worth, lynx is my preferred browser for all web browsing.

nkozi
nkozi

Tip: When doing browser tests on Safari, run your tests for both the Windows and OS X versions of the browsers. There are quite a few differences in behaviour between the two flavours of the browser, which are also not always consistent.

Justin James
Justin James

It would be a lot better for all concerned if the W3C would get off their duff and really sort the multimedia situation out. All they need to do is define a tag that says, "here is a mime type" and the dimensions of the player, and let the client sort it out; that would be the most appropriate and consistent way of handling this. But it also reflects on HTML's roots and purpose. Where does embedding multimedia fit into the goals of HTML? It doesn't. Thus, the paradox. It's another case of our usage of HTML having long outgrown HTML as a framework or a concept. We no longer truly want HTML or something similar, we really want a remote windowing system. Like SMTP and the SSL certificate system, this is yet another standard which was designed for an era long ago, but we are stuck with for reasons of momentum. J.Ja

Jaqui
Jaqui

just code it to all w3c standards, including the WAI and have a disclaimer that the site works just fine, when the browser supports standards. if the visitor is having a bad visit, it is the direct fault of whoever made their browser. that will promote standards compliant browsers even more.

Justin James
Justin James

... is that you get to see what your site looks like to a search engine. It is invaluable for SEO work. Oh, your site uses AJAX to show most of the text or links? Well, Lynx won't see it, so neither will Google. Last I checked, search engines don't activate "onMouseOver" events. ;) J.Ja

Jaqui
Jaqui

a very useful tool. design any site to function well with it and you have a site that will work for anyone. it may not have all the bells and whistles of a multimedia website for most functionality, but everyone will be able to access it and get something from it. since I forgot to include the: Lynx does NOT support flash. in the earlier post. :D [ youtube fails miserably with lynx, but then so does TR ] edit to add: you are right, using lynx to view a site is exactly what a search engine bot will see. though TR seems to have sidestepped the javascript issue with the bots somehow.

Justin James
Justin James

... that I don't do browser detection. For the rare occassions I used JavaScript, I keep it simple, and don't make it mandatory to use the site; I typically use JavaScript to put dumb little "hover" effects on stuff, to make a client think they are getting a "cool" site. J.Ja

Jaqui
Jaqui

screws that up. ;) several browsers offer the functionality of turning off all user agent data, so browser, os, screen resolution, plugins installed etc are not ever sent to a website.

Justin James
Justin James

A lot of people do that with browser detection, give a plain text version of the site to a search engine. Too bad the search engine's terms clearly state that they can (and will) drop you for this if anyone reports it. :) J.Ja

Editor's Picks