7.7. Testing JavaScript

With layout issues, each browser also renders JavaScript differently. The same JavaScript can work perfectly in one browser while being completely broken in another. We have already described the different approaches you can take to test a site on multiple browsers, but as you are testing the site you should also keep in mind that JavaScript also behaves differently on each of those browsers. As such, you should be aware of how JavaScript is used on the site, and how it might work differently on the different browsers.

To help test JavaScript there are a number of different browser plug-ins which allow you to debug and profile scripts as they are executing. Each browser has their own set of tools, for example Firefox has FireBug (https://addons.mozilla.org/en-US/firefox/addon/1843), while IE8 and Safari both have built-in tools. These tools are always handy to have installed as they can help identify why the scripts are failing and help you pinpoint the problem.

These tools also have the ability to disable JavaScript and CSS. Disabling JavaScript is not as common as it used to be, however you may find certain people have disabled it for security reasons and due to accessibility issues. By using these browser tools you can see how the site would function with various parts of the site disabled.

Luckily, the issue of cross-browser testing and JavaScript is not the major problem it used to be thanks to jQuery (http://jquery.com/). jQuery abstracts away from the underlying JavaScript and as such abstracts away from to code to support cross-browsers with the core framework supporting all the major browsers out-of-the-box without any additional effort. By relying on this level of abstraction, your code is not only cleaner but also requires less testing. As a developer, you should be considering this when you are using JavaScript. If you are a tester, then you should be encouraging the development team to look at this due to the decrease in the amount of testing required while at the same time speeding up development.

Although jQuery removes how much basic testing is required based on different browsers, it does allow for more advanced functionality. More advanced functionality is more difficult to test using frameworks such as WatiN, as we discussed in Chapter 5. Personally, we feel that these effects should not be automated but manually tested. To manually test this functionality you need to use exploratory testing and see the functionality from the viewpoint of the end-user and decide if you think you are happy. There are no special tricks or best practices. Use the application, see the application from the users' eyes, and decide if you think they would be happy.

This could be an ideal time to bring in external users and beta testers to help you test the functionality to see if it is working as expected and desired. Beta testers are a great way to see if the users are happy with the functionality and the implementation. This can provide you with some feedback while there is still time to change the functionality before releasing it to the general public. The closer relationship you have to beta testers, the higher-quality feedback you receive that will result in a better product being produced.

Sadly, we can't rely on beta testers to test that every part of the application works successfully. To verify this we could use exploratory testing, however this is mainly powerful during the learning and exploring stages and becomes less useful the more times you do it. The answer could be to write test cases.