Web application testing is different from a desktop testing application. Rob Lambert, also known as the "Social Tester," explains why this is so in his resource-filled e-book, 36 Days of Web Testing.
When asked which three lessons he believes are most valuable, Lambert highlighted the following: the chapter on browser extensions, because it highlights some invaluable tools at a tester's disposal; the Web accessibility chapter, since he believes we should all be making the Web a more accessible place; and the client- and server-watching chapter, because this can lead you to some of the most critical bugs in your products.
In this tip, we'll take a look at these three areas of Web application testing and explore some of Lambert's recommendations.
One of the reasons Lambert's e-book is so useful is that it is filled with hyperlinks to a multitude of resources. Unlike a book you'd pick up off the shelf at a bookstore, an e-book allows easy access to a wealth of additional valuable resources. This concept of open sharing is further demonstrated by the tools that are highlighted in the Browser Extensions chapter of 36 Days of Web Testing.
Unlike other chapters, which typically highlight and demonstrate a type of Web test, the Browser Extensions chapter highlights add-ons and plug-ins to browsers that Web testers will find useful. Lambert adds that there are more available than he can list and that URLs may change, but the list is useful for a new tester to learn about some of the most popular Web testing tools that are available.
Testing must go beyond simply running a tool.
This chapter starts with the Selenium IDE tool. This open source automation tool is very popular in the Web application testing industry because it allows for record and playback and scripting in a variety of languages. SearchSoftwareQuality published "Tutorial: Introducing Selenium IDE, an open source automation testing tool,"which goes through Selenium Remote Control (Selenium RC), installing and running Selenium RC in Perl, and using Selenesse, a combination tool from FitNesse and Selenium.
But Selenium IDE is only the first of several extensions that Lambert's book recommends. With each tool, he provides a link and a short description. Examples are IE Tab for flipping your Firefox tab to Internet Explore mode, Firesizer for resizing your window, and the popular Firebug, which allows many development tools to run while you are using the Firefox browser.
Web accessibility testing is designed to make sure that websites take advantage of features to help users who have disabilities. One example of this would be to ensure that text-to-speech functionality is implemented properly so that visually impaired people can take advantage of this feature. Allowing for text and images to be enlarged or for images to have tags that describe what the images are, are features that will help users who are not able to see clearly. Color blindness must also be taken into account with Web design. Likewise, there are features that can be implemented to help those with hearing, seizure and learning disabilities, among others.
In Lambert's chapter on Web accessibility testing, he reminds us that there are tools that will test for things such as HTML compliance, but that our testing must go beyond simply running a tool. For example, the alt text attribute allows for a text alternative for an image to be identified. This will allow a visually impaired user with the proper screen-reader software to listen to a spoken version of the text associated with that image. However, if no value has been given for the alt attribute, this feature will fail.
While an automated checker can easily detect that the alt attribute is missing, it will not check to make sure that the text description actually matches the image. "Your picture could be of a red apple, and the text you entered could read 'cute cuddly brown teddy bear,'" quips Lambert. He also reminds us that automated checkers cannot check flow and logic. He suggests that the best people to provide feedback for end-user accessibility tests are those who will be ultimately using the software.
Client and server watching
Though transparent to the user, Web applications are communicating between a client's browser and a Web server. Understanding the messaging between these two pieces is critical in determining useful tests that will help expose weaknesses in functionality, security and performance.
Lambert steps through a very simple example of a login. Even though this is one of the most basic actions that almost every Web application employs, there are messages and logic that take place both on the browser side and the server side.
Web testers must be checking to make sure the data that is being sent between client and server is correct, that the appropriate actions take place if there are time-outs, and that response times meet requirements.
This was first published in April 2013