How to Test Web Applications
Testing Web applications is very different to testing Windows based applications and this document aims to identify key areas of testing, error reporting and common issues in this area.
It is also designed to cut down on time required to gather required information so that more time can be spent fixing issues.
This is not designed to be a definitive guide, but more of a starting point for web testing.
How to Setup for Testing
IE Developer Toolbar
It docks to the bottom of the window, once activated from the tools option.
Also ensure that under Tools->Options->Advanced that “Disable script debugging” is unchecked
Note: IE8 has its own debugger built in, and therefore this toolbar does not need installing but ensure the “disable script debugging” is unchecked. If trying to track down a problem, which is not displaying or showing in the normal browser, click “Start Debugging” in the Debugger after choosing it from the menu or pressing F12.
Firebug is an addon to Firefox and is extremely useful in debugging Web Applications.
Once installed, firebug adds a panel to the bottom of the browser, which can be activated by clicking the firebug icon in the bottom right. It can also be removed to a floating window.
Like IE8, this is built into the browser. Choose Preferences, Advanced, then select the “Show Develop menu” option. This then adds similar options to Chrome (see below) and also opens in a floating window.
Chrome has a built in debugging console, so I simply recommend that you open this prior to testing.
Things to Test
As well as standard test plans; there are other points that should be specifically tested:
SQL injection is a trick to inject SQL queries/commands as an input via web pages. Many web pages take parameters from web users and make SQL queries to the database. Take for instance when a user logs in: the web page uses an SQL query to the database to check if a user has valid name and password. With SQL Injection, it is possible for us to send a crafted user name and/or password field that will change the SQL query and thus grant us access to other data.
All form fields that communicate with a database (e.g. Login Form, Add User, Save Settings) are potentially vulnerable.
For more details and for how to test please see:
Spurious and Foreign Characters
Some characters can cause websites problems – These include, but are not limited to commas, quotes, double quotes, ampersands and brackets.
This is because these characters are used within the coding language itself to terminate strings and function names etc.
The code then does not know what to do with these additional characters and throws an error. These errors can be a simple display issue, or the whole application can crash.
These items need to be tested within areas that then display within the web application. For example, username, configuration options and titles are ideal locations to try and enter these characters to see if the field handles them correctly.
Foreign characters can often be changed into their relevant HTML codes that can start with ampersand or hash causing the same issues as above.
Obvious, but needs checking as there are still spelling mistakes in many Web Applications.
Common Issues between browsers
As well as the issues identified above, there are often differences between the ways that browsers display the same information:
Spacing + Rendering
Often Internet Explorer will decide to display padding and margins on HTML elements differently to other browsers. Therefore, it is important that all web applications look similar and correct in different browsers. This does not have to be exactly the same, but must look correct in isolation.
Languages and Character Display
Different browsers should display character sets the same but there can also be some differences in rendering of characters.
More people visited the World Wide Web Consortium (W3C) website using Firefox or Chrome than Internet Explorer in Oct 2010. This shows that this is a very important area to look at.
Client Side vs. Server Side Errors
There are 2 different types of errors you will encounter when testing web applications:
Server Side Errors
These errors will normally stop the application from working all together and you will receive an error message on the screen. This could be something like an error connecting to the database or an error in the code itself.
In many Web Applications, when a Server side error occurs, they display a friendly message to the users instead of the actual error message, although the full error message is sometimes also accessible.
Client Side Errors
These errors normally do not stop the whole application from working and the error will normally not appear within the actual webpage.
These errors may cause functionality errors, e.g. tabs not closing or buttons not working.
Client side errors are trapped in the debugging tools relevant for each browser detailed in this document.
How to report a problem to a Developer
The first and most important things to note when reporting are the exact steps taken to reproduce the issue – including relevant details. E.g., The username you are entering or the name of the user you added when the problem occurred or other data you have entered into a form.
Also, important to note is the Browser Type (e.g. Internet Explorer, Firefox), the browser version (available from Help->About) and the Operating System as there are often subtle differences between using the same browser but on different Operating Systems.
If an actual error occurs, then we need the error message too:
For a client side error, you can copy the error from one of the debugging tools listed at the top of this document.
For server side errors, we need the full details sent back from the server – if available.