In the last three years many JavaScript frameworks with AJAX support have become available from open source projects and commercial vendors. These include Prototype, script.aculous (which is built on top of Prototype), Dojo, Google Web Toolkit (GWT), DWR, Tibco General Interface, Yahoo UI, and many, many others.

These capabilities continue to evolve rapidly and Web developers now have a wide array of powerful UI tools they can use to build their Web applications.

The toolset for the QA staff responsible for testing and certifying AJAX applications hasn't caught up yet with the capabilities being offered to Web developers. Currently most AJAX testing is being done manually.

Modern Web applications have n-tier architectures that communicate via messaging. A new generation of testing tools will provide recording of and visibility into the detail message events that affect the function of AJAX UIs.

For the first time, application testers need to understand the structure and semantics of the messages (down to the packet level) being exchanged to design tests for these applications.

What's the Problem? Why is AJAX Testing So Hard?
The problem with AJAX testing is that there are immediately multiple event streams that can affect the User Interface — first, the user events that we are accustomed to (clicks, drags, typing, drags, drops), and second, the asynchronous message events (that can have many simultaneous open requests) that are sent to the Web server. The uncertainty about the timing and sequence of the responses to the AJAX message requests introduces a lack of determinism into the testing that the test designer needs to handle properly.

Test validations can fail because the element being tested hasn't been populated yet by the AJAX response. One solution is to put a pause before the validation, but this is fragile, since the timing of the pause might not be sufficient on a slow machine, while being unnecessarily slow on a faster one. The timing and sequence of message responses can vary widely based on server load and available bandwidth so any test that depends on timing is problematic.

In this simple HTTP recording, four requests are sent to the Web server. The messages and packets from the responses are color-coded. As the following series of screenshots shows, the response packets for Message 2 return to our browser after the responses to Message 3. Testers must deal with this uncertainty in the design of the testing.

This is a very simple example. Real world scenarios are more complex.

What About Cross-Browser Testing? Do I Have To?
In June 2004, Microsoft Internet Explorer (IE) had a 95% share of worldwide browser use. It was very common for Web developers to build their Web sites and applications only for IE. While IE remains the market leader, the picture is now very different.

By September 2007, Internet Explorer had declined to 64% of worldwide browser use with the prospect of further decline now built into the market's expectations.

The introduction of full browsers on smartphones in 2007 (think iPhone) will accelerate this cross-browser requirement. These smartphone users are one of the world's most affluent demographics. Your Web site will need to work on their device.

Cross-browser testing is now mandatory. Your AJAX testing approach will need to address this requirement.

What About Flex? I Have Pages That Use AJAX & Flex
You are an AJAX developer and really believe that it's the best technology available for building rich Web UIs. Would you use Flex or Flash? You might not have a choice. Increasingly, marketing VPs around the world are using rich media (video, audio, flash presentations) to make product information, training, and demonstrations easily accessible to prospects and customers. Adobe Flex and Flash technology excels at the fast and efficient delivery of this content across the Web.

Until recently, the only automated testing tool for testing Flex components and applications was a special version of Mercury's QTP (this version was only available from Adobe). In October 2007 Adobe provided access to the Adobe automation interface to testing companies, and in the next six months third-party tools will come to market incorporating the capability to test Web pages with mixed content.

What AJAX Testing Tools Are Available?
There are a number of open source and commercial offerings that support testing GUIs including browser-based UIs. Some of them are:
Open Source
•   Selenium
•   Watir, FireWatir, SafariWatir
•   Web Driver
•   PushToTest

Commercial Products
•   Mercury QTP
•   Silk
•   SWEA
•   Parasoft
•   Squish

The offerings that support AJAX testing are dominated by developer-focused, code-driven frameworks. They support AJAX testing by allowing the tester to write code that tests the browser UI. Many of the commercial offerings don't support AJAX testing yet. The effort to write the test code can be time-consuming and expensive.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6