Cross Browser Testing

Go back to Tutorial

With wide range of web browsers available, end users using different web browsers to access your web applications, it has now become crucial to test web applications on multiple browsers. On different browsers, client components like JavaScript, AJAX requests, Applets, Flash, Flex etc. may behave differently. Also for different browsers you may have different handling on how requests are processed on server side based on the user-agent received from client browser. So just testing your web application on single web browser is not enough. You need to make sure that your web application works fine across multiple browser. Cross Browser Testing is a process to test web applications across multiple browsers. Cross browser testing involves checking compatibility of your application across multiple web browsers and ensures that your web application works correctly across different web browsers. Cross Browser testing involves testing both the client side and server side behavior of your Web application when it is accessed using different Web Browsers.

• Client Side Cross Browser Testing
• Server Side Cross Browser Testing

Web-based applications are totally different from Windows applications. A web application can be opened in any browser by the end user. For example, some people prefer to open http://twitter.com in Firefox browser, while other’s can be using Chrome browser or IE.

So we need to ensure that the web application will work as expected in all popular browsers so that more people can access it and use it.

This motive can be fulfilled with Cross Browser Testing of the product.

Cross Browser Issues

• Font size mismatch in different browsers.
• JavaScript implementation can be different.
• CSS,HTML validation difference can be there.
• Some browser still not supporting HTML5.
• Page alignment and div size.
• Image orientation.
• Browser incompatibility with OS. Etc.

Performing Cross Browser Testing

It can surely be done manually- multiple machines, multiple OSs, Multiple browsers, multiple machines and but clearly, this leads to multiple problems, multiple investments and multiple challenges.

Manual Method – In this case, a business identifies the browsers that the application must support. Testers then re-run the same test cases using different browsers and observe the application’s behavior and report bugs if any.

In this type of testing, it is not possible to cover many browsers and also, the application might not be tested on major browser versions. Also, performing cross-browser check manually is costly and time-consuming too.

Automated Method – Cross-browser testing is basically running the same set of test cases multiple times on different browsers.

This type of repeated task is best suited for automation. Thus, it’s more cost and time effective to perform this testing by using tools.

Workflows for cross browser testing

All of this cross browser testing business may sound time consuming and scary, but it needn’t be — you just need to plan carefully for it, and make sure you do enough testing in the right places to make sure you don’t run into unexpected problems. If you are working on a large project, you should be testing it regularly, to make sure that new features work for your target audience, and that new additions to the code don’t break old features that were previously working.

If you leave all the testing to the end of a project, any bugs you uncover will be a lot more expensive and time consuming to fix than if you uncover them and fix them as you go along.

The workflow for testing and bug fixes on a project can be broken down into roughly the following four phases (this is only very rough — different people may do things quite differently to this):

Initial planning > Development > Testing/discovery > Fixes/iteration

Steps 2–4 will tend to be repeated as many times as necessary to get all of the implementation done.

Initial planning – In the initial planning phase, you will probably have several planning meetings with the site owner/client (this might be your boss, or someone from an external company you are building a web site for), in which you determine exactly what the web site should be — what content and functionality should it have, what should it look like, etc. At this point you’ll also want to know how much time you have to develop the site — what is their deadline, and how much are they going to pay you for your work? We won’t go into much detail about this, but cross-browser issues can have a serious effect on such planning.

Once you’ve got an idea of the required featureset, and what technologies you will likely build these features with, you should start exploring the target audience — what browsers, devices, etc. will the target audience for this site be using? The client might already have data about this from previous research they’ve done, e.g. from other web sites they own, or from previous versions of the web site you are now working on. If not, you will be able to get a good idea by looking at other sources, such as usage stats for competitors, or countries the site will be serving. You can also use a bit of intuition.

So for example, you might be building an e-commerce site that serves customers in North America. The site should work entirely in the last few versions of the most popular desktop and mobile (iOS, Android, Windows phone) browsers — this should include Chrome (and Opera as it is based on the same rendering engine as Chrome), Firefox, IE/Edge, and Safari. It should also provide an acceptable experience on IE 8 and 9, and be accessible with WCAG AA compliance.

Now you know your target testing platforms, you should go back and review the required featureset and what technologies you are going to use. For example, if the e-commerce site owner wants a WebGL-powered 3D tour of each product built into the product pages, they will need to accept that this just won’t work in IE versions before 11. You’d have to agree to provide a version of the site without this feature to users of older IE versions.

Once you’ve agreed on these details, you can go ahead and start developing the site.

Development – Now on to the development of the site. You should split the different parts of the development into modules, for example you might split the different site areas up — home page, product page, shopping cart, payment workflow, etc. You might then further subdivide these — implement common site header and footer, implement product page detail view, implement persistent shopping cart widget, etc.

There are multiple general strategies to cross browser development, for example:

• Get all the functionality working as closely as possible in all target browsers. This may involve writing different code paths that reproduce functionality in different ways aimed at different browsers, or using a Polyfill to mimic any missing support using JavaScript or other technologies, or using a library that allows you to write a single bit of code and then does different things in the background depending on what the browser supports.
• Accept that some things aren’t going to work the same on all browsers, and provide different (acceptable) solutions in browsers that don’t support the full functionality. Sometimes this is inevitable due to device constraints — a cinema widescreen isn’t going to give the same visual experience as a 4″ mobile screen, regardless of how you program your site.
• Accept that your site just isn’t going to work in some older browsers, and move on. This is OK, provided your client/userbase is OK with it.

Normally your development will involve a combination of the above three approaches. The most important thing is that you test each small part before committing it — don’t leave all the testing till the end!

Testing/discovery – After each implementation phase, you will need to test the new functionality. To start with, you should make sure there are no general issues with your code that are stopping your feature from working:

• Test it in a couple of stable browsers on your system, like Firefox, Safari, Chrome, or IE/Edge.
• Do some low accessibility testing, such as trying to use your site with only the keyboard, or using your site via a screen reader to see if it is navigable.
• Test on a mobile platform, such as Android or iOS.

At this point, fix any problems you find with your new code.

Next, you should try expanding your list of test browsers to a full list of target audience browsers and start concentrating on weeding out cross browser issues. For example:

• Try to test the latest change on all the modern desktop browsers you can — including Firefox, Chrome, Opera, IE, Edge, and Safari on desktop (Mac, Windows, and Linux, ideally).
• Test it in common phone and tablet browsers (e.g. iOS Safari on iPhone/iPad, Chrome and Firefox on iPhone/iPad/Android),
• Also do tests in any other browsers you have included inside your target list.

The most low option is to just do all the testing you can by yourself (pulling in team mates to help out if you are working in a  team). You should try to test it on real physical devices where possible.

If you haven’t got the means to test all those different browser, operating system, and device combinations on physical hardware, you can also make use of emulators (emulate a device using software on your desktop computer) and virtual machines (software that allows you to emulate multiple operating system/software combinations on your desktop computer). This is a very popular choice, especially in some circumstances — for example, Windows doesn’t let you have multiple versions of Windows installed simultaneously on the same machine, so using multiple virtual machines is often the only option here.

Another option is user groups — using a group of people outside your development team to test your site. This could be a group of friends or family, a group of other employees, a class at a local university, or a professional user testing setup, where people are paid to test out your site and provide results.

Finally, you can get smarter with your testing using auditing or automation tools; this is a sensible choice as your projects get bigger, as doing all this testing by hand can start to take a really long time. You can set up your own testing automation system (Selenium being the popular app of choice) that could for example load your site in a number of different browsers, and:

• see if a button click causes something to happen successfully (like for example, a map displaying), displaying the results once the tests are completed
• take a screenshot of each, allowing you to see if a layout is consistent across the different browsers.

You can also go further than this, if wished. There are commercial tools available such as Sauce Labs, Browser Stack, LambdaTest, TestingBot, and CrossBrowserTesting that do this kind of thing for you, without you having to worry about the setup, if you wish to invest some money in your testing. It is also possible to set up an environment that automatically runs tests for you, and then only lets you check in your changes to the central code repository if the tests still pass.

Go back to Tutorial