Testing Web Applications

Introduction

Web applications have many additional challenges compared to traditional applications as the users can have different browsers, devices and operating systems, monitor sizes and resolutions, as well as different connection speeds. They may reside in different countries which might involve translations and currency conversions. In terms of security, the mere fact that the application is accessible by the whole world makes it more vulnerable to attacks.

According to Myers (2004, pp. 5-9), one of the “primary causes of poor program testing” is the fact that “most programmers test the programs trying to prove that errors are not present” and that “the program performs its intended functions correctly”. Testing should start with the assumption that the program contains errors and that it should be tested in order to find as many of them as possible, and to fix them.

Web applications should be tested at presentation, business logic and data layers and within each layer a number of different testing activities should be performed. This includes layer-specific techniques, for example checking for broken links or data recovery possibilities, as well as common techniques like code inspection and black box testing for pre-determined test cases. Discovered errors should be fixed as soon as possible and the testing should continue until no more errors are found. In addition to this, a higher order testing should be undertaken to see if “big picture” requirements are satisfied, and load testing should help to verify application performance and behaviours under heavy user load.

One major rule of Web application testing are that it should be conducted in a replica of production environment. This means that the web, application and database servers and all network infrastructure used in testing should be exactly the same as in the final production implementation of the application.

Another important rule is that the application developer and the application tester must not be the same person.

Presentation Layer

This is the only layer that customers see. In e-commerce this is the front end which creates the impression on the whole company and has a major influence on their decisions on buying the products or not. As Myers (2004, p. 202) bluntly puts is, “if your company creates Web pages with misspelled words, it cannot be trusted to successfully execute a credit card transaction.” Therefore the importance of this layer cannot be overestimated.

Myers (2004, p. 202) mentions that testing of this layer is very labour intensive. Usually a fully operational site is intended to have hundreds or thousands of pages and when the presentation is dynamically created, it is often impossible to test every single possible page. In general these dynamic pages are based on page templates of some sort, combined with the data stored in a database, and the most appropriate forms of testing them are boundary range analysis. Test cases should created with relevant values being close to or at ranges of acceptable boundaries. It is important to note that the analysis of this layer does not include testing for invalid values, as the validity of data is confirmed at other layers. In most cases range boundaries can be set by business logic and data layers that define required and acceptable values and, accordingly, identified errors need resolution within these layers. In other cases, however, missing information will be acceptable as it is optional, and it is the presentation layer that needs to be adjusted for this possibility. In some occasions the range boundary can too big to be applied so an arbitrary number can be used to test the layout. (For example, a shop can in theory receive an infinite number of orders.) This layers should be regression tested in the sense that after the errors were corrected the tests should be repeated until the results are correct and free of not only these identified errors, but also of any further ones.

All static pages and all dynamic pages for given test cases should be tested for:

• Overall look and feel
• Fonts, colours and graphics
• Spelling
• Content accuracy
• Graphic sizes
• Page sizes in KB
• Cursor positioning when page loads
• Default form buttons when page loads
• Different screen size (800 X 600, 1024 X 768 and 1280 X 1024 pixels)
• Different browsers (Internet Explorer, Firefox, Chrome, Safari...)
• Different default locales
• Behaviour with or without enabled JavaScript
• Page resizing

All dynamic pages must be tested for default values, i.e. what happens when no parameters are specified.

The whole site must be tested for any broken hyperlinks or missing graphics. However, correct navigation is more than lack of broken links so the site must also be manually checked for presence of correct links, behaviour at decision points and proper navigation paths.

As far as the forms on the site are concerned, at this stage only the form layout should be tested. The system response for different user data can be better tested within the second stage when we look at the business logic layer.

If pages contain ActiveX components, Java applets or VB script appropriate related testing is needed.

Business Logic Layer

In the previous section we tested how the user data affect visual representation, now we test how it affect business logic.

Code Inspections and Walkthroughs

Analysis of business logic layer started with “human” testing which involved reading through the code and looking for errors. The advantage of using an IDE (like, for example, NetBeans or Eclipse) is obvious as most errors are highlighted and the application is prevented from deploying until they are corrected. Nevertheless, every single piece of code was manually reviewed and checked for errors.

White Box and Black Box Testing

White box testing involves examination of internal program structure and logic and “execution of all possible paths of control flow through the program”, whereas black box testing is focused on “finding circumstances in which program does not behave according to its specification” (Myers, 2004, pp. 9-11). However, in testing Web applications these activities in most cases overlap, due to the fact that they are based on HTTP request and response and that the use cases usually involve granular functions. While test cases are typically designed from a black box perspective, they can also make sure that all programming paths and methods are covered.

Data Layer

Firstly, data layer testing is often performed simultaneously with black box testing described above and data integrity should be verified for all test cases, whenever applicable. While the data validation in previous section attempted to find errors in data collection, data layer testing was focused on data integrity and finding errors in how data is stored in the database. Data fields must be tested not only for length and type but also for Unicode character support.

Secondly, as the database should also be valuable and fully functioning on its own without the rest of the application, tests for referential integrity should be performed separate from application testing, to determine and improve database behaviour in cases of deletion or modification of index keys.

Higher Order Testing

Most of the function testing was already performed in previous steps, however, this involved only modular user actions, and at this stage a more comprehensive paths should be tested. While test cases are essentially the same as in previous sections, they should be placed in order of operational logic.

Higher order testing should also include volume testing, with using high volumes of data, and stress testing, with high volumes of data in short time intervals. There should also be performance, storage, reliability and recovery testing. As mentioned in the introduction, to properly test the application using these methods it is necessary to duplicate the production environment. This includes using not only Web, application and database servers that are identical to the production equipment, but also the network infrastructure, including, for example, routers and switches.

Load Testing

Load testing involves “blasting the application with multiple logins and simulating transactions to the point of failure” (Mayers, 2004). The same author mentions that “very often, system performance degrades to the point of being unusable when the system becomes overloaded with requests” and the approach used here is that, in order to determine the limits, we increase number of simultaneous users until the system fails to meet requirements.

An example of a good load testing tool is an open source application WebLOAD, from RadView Software. WebLOAD has ability to load different agendas for different users and although they are accessing the site at the same time, they are performing different actions.

Testing scripts should try to emulate typical user actions for different user groups.

Testing with Users: Usability and Acceptance Testing

All users involved in testing of the application should be able to easily understand the functionality and perform necessary steps with minimal guidance. In testing process it is important to see if all needed use cases were implemented and if the complete product would meet end user acceptance.

All testing by users should not be done in presence of one of application developers, and if possible users should be left to work independently for a certain period of time.