amillionlittlepieces

UK technology trains of thought...

Tuesday, February 14, 2006

AJAX & Software Quality

If you have been following some of the developments in web-technology over the last year, you will have heard of AJAX – the latest approach to creating rich, interactive web content. Similarly, if you have used any of Google’s perpetually ‘beta’ products this year you might have noticed that they are very responsive compared to some of their competitors.

Before I define AJAX, and how it affects test and quality professionals, let me give you a real example. If you go to http://www.multimap.com and enter your current location, you will get a map of the area. Now if you change the zoom factor, the page will reload and display a different level of detail.

This ‘reload’ has been the accepted paradigm for most web applications since the dawn of the web. The only exceptions to this are executables that download and run within the browser such as Flash and Java Applets. However a long download time, and the need for third party software and plug-ins.
To demonstrate the power of AJAX, visit http://maps.google.com and follow the same process. You will notice that the application appears to present the results of changing the zoom level faster; the more observant will notice that the page itself does not appear to reload or change. This is exactly the purpose and the raison d’ être for AJAX.

When you change the zoom level at Multimap, it is not only changing the image, but repeating requests done earlier to find other information about the area, finding appropriate adverts etc. In effect, it is starting again.

So what is AJAX?

The way it works is by using a combination of XML and JavaScript to asynchronously update the page. This means that the request for a certain part of the page is not linked to the response that displays the results. AJAX enables a part of the page to be updated without a reload of the rest of the page.

Technically, this has been done before – and this is one criticism that has been levelled at the AJAX hype. However this is the first time it has been brought to the mainstream under a single banner, using standards based technology rather than proprietary add-ons.

AJAX is an acronym for Asynchronous Java And XML. The way it works is by using JavaScript in the HTML to consider the rendered web page as an XML object. This means it can be manipulated using the widely-supported Document Object Model (DOM). Because of the wide support for JavaScript, XML and DOM – developers can rely on AJAX working in most modern browsers.

It should be emphasised that AJAX is not a technology, or something you can tangibly download or install, it is simply a design approach that has gained popularity. This is primarily down to it’s adoption by Google and Yahoo for their forward-looking beta projects.
AJAX and Quality

Every software quality professional knows that improving quality is always a trade-off, and that with new and immature technologies this is even more acute.

The performance enhancements that AJAX offers will transform users expectations of web based applications. Full reloads of the page will become analogous to looking at a static list of data on a command line, rather than looking at a constantly updated screen. New applications will be enabled by the technology, with a richer and more interactive feel.

If you are reviewing a web application project in it’s early stages, you should be asking – what will the users perception of reasonable performance be from this application by the time the project has finished? It used to be acceptable for web pages to load in ten seconds – that is certainly not the case any more, nor is it excusable with the advent of high-speed internet.

However this approach is not a silver-bullet. As I said before there are always trade-offs with such decisions, in this case they lie with usability, accessibility, security and testability. These all have technical solutions, but as I said this is immature technology and should be treated with care.

Firstly, with usability there are a number of concerns that need to be addressed in AJAX projects. Because the page load is no longer ‘atomic’, i.e. a single transaction, you cannot expect the standard ‘back’ and ‘forward’ browser navigation functionality to work as normal. The very concept of AJAX abandons the concept of a static page, and with it goes the simplicity of navigation functionality. This can be resolved in a number of ways; however there is no standard solution.

Another area of concern is that copying and pasting, or bookmarking the URL may not work. Again, because we are no longer dealing with a static page – you cannot automatically expect a single point of reference to that page to work. This isn’t unfamiliar ground however; some web applications have not worked like this for some time – although that doesn’t make it less irritating!

In terms of accessibility, some projects may have legal requirements upon them that mean they need to comply with certain restrictions, others may simply be aiming to reach their audience, but dynamic web pages is not something that sits well with many accessibility solutions. The main response to this at the moment is to provide a less interactive and dynamic version of the page for users that wish to use special browsers or other technology.

Security is another issue that needs to be properly assessed, using AJAX means putting dynamic code in the publicly viewable portion of the web application. This means anyone can see how the page is calling your servers. This easily worked around through obfuscation, but it is wise to check that you are not exposing too much information to the user – especially if the JavaScript is calling a different server to the main web server.

Another concern with security from a user point of view is that they will need JavaScript turned on in their browser, or ActiveX if they use Internet Explorer. These represent high-risk areas within a browser and the more paranoid user may have them turned off.

Most easily forgotten in all this is the testability of your application. The more you shift the onus on to the client-side rather than the server-side, the more you stand to lose in logging capability. There are plenty of ways to address this, including an open-source project called Log4AJAX – however a little planning upfront should ensure you don’t waste hours looking in the wrong place for an error hidden in your Internet Explorer logs. Ensuring log messages are dealt with correctly will also be critical for thorough beta testing.
AJAX and Testing
Even if you are black-box testing, testing AJAX applications is neither like testing interactive web pages, nor like testing desktop applications. It is most like testing a Java applet, but without as clear a boundary between the client and server or a conventional user interface.

The diagram below illustrates the three threads that will be executing. Firstly the browser will initialise the page and it may at this point set up a JavaScript loop that can update variables, contact the server and update the page through the DOM.

Another thread will be listening for remote function calls (usually in XML) from the server. This can be called at the discretion of the server, by the loop launched at initialization, or by a third thread that responds to user events.

Because the threads managing the request and response to requests are not synchronised, the user can cause more than one type of user event before the last has even started. This is not usually possible in many modern user-interfaces. If you have three different data items on your screen to be updated every minute, and three processes that can be triggered simultaneously on the server through a user event – you can end up finding it very difficult to test all permutations of client and server side states. This is of course augmented when you inevitably have more than one user!

The interactions between the threads, users and functions something that should be a focal point of design and code reviews – to ensure all design is streamlined be ‘bulletproof’ in case of unexpected events. Defining functions as ‘services’ that are autonomous of each other is way of doing this that is gaining popularity.

Applying a risk-based approach to the potential events is necessary to prioritise testing, and this requires close integration with the development team. Key areas of functional risk sit around:
  • transactions that impact data that is being continuously updated elsewhere;
  • multiple transactions launched from the same page that may use the same logic or data;
  • corruption caused by using the ‘back’ or ‘refresh’ button;
  • multiple transactions launched from the same page where one impacts the dependency of another.
As the response to the remote call is separate from the request, testing using web-services based tools, including tools that create HTTP requests, are limited in the way they can replicate the user experience. Also, tools that are accustomed to testing the end user interface, may not be designed to trigger multiple events at once and correctly capture the response.

There are testing tools that can help massively with testing the pages, certainly the open-source Selenium has the ability to wait for the callback – and this puts it well ahead of the hype curve on AJAX.

In conclusion, AJAX is a new type of solution that will bring a new level of functionality to the ubiquitous web based application. Although is still a web page, it has new considerations in terms of the quality considerations, functional risks, and technical approach.

technorati tags: , ,


2 Comments:

At 8:48 PM, Blogger Pip said...

"AJAX is an acronym for Asynchronous Java And XML."

Javascript!!!

Good piece though, I'll be pointing my team at it.

 
At 2:34 PM, Blogger hazelle said...

me also. it about time you posted some more top tips for budding developers such as myself. the last one was in feb dont you know!

 

Post a Comment

Links to this post:

Create a Link

<< Home

Property in France