What Are Some Unobvious Differences Between Testing a Web Application and a Desktop Application?

Question

In the same flavour of this question, what are some unobvious differences between testing a web application and a desktop application? I've recently started looking at automating some GUI tests for a web app using SilkTest. There are some subtle differences between automated GUI testing between web and desktop apps, such as how control events are handled (button clicks, scrolling, etc). I also know there are network aspects such as load and performance testing, which don't necessarily come into play with desktop apps but are significant in web testing. Coming from a desktop app background, what are some other things I should look into or consider?

Answer 1

• Desktop software usually requires installation. Web applications usually do not.
• But web applications are sometimes expected to be running 24x7. This can make upgrades and maintenance more of a challenge to plan and execute (and thus test)
• In addition to browser versions mentioned by others here, you may need to worry about browser add-ons
• You may also need to worry about the myriad browser settings that could cause issues with your web application
• Some desktop applications are designed for single users. By definition, almost all web applications are multiple-user systems. You need to worry about concurrency, what happens when the same user is logged in multiple times, etc, etc.

Answer 2

• Combinatorial explosion of varieties: You may need to test each version of each browser on various hardware running various operating systems

• Front-end testing can be easier because of the universality of the displayed information

• When you do performance/load testing you're simultaneously testing the machine the server is on, not the current desktop (unless they're the same, obviously).

• You may need to test on mobile devices, as they can access the web too. In fact you may need to validate your html to certain standards such as usability for disabled users, etc. A visit to http://www.w3.org/ might be in order.

• Security, as mentioned

• You have many more open source tools to help you (watir-webdriver is a good example)

Answer 3

Apart from "what those other guys said", all of it very good advice, some other considerations I'd recommend are:

• Usability - Desktop applications tend to have a help file built in, where web applications should be more or less self-explanatory.
• Load times - this one is a big pain point. Not everyone has broadband (and we won't go into how much I despise pages that have so much advertising attached that they take eternity to load despite broadband) and there are quite a few people who operate on extremely limited connectivity. You should look to test that your site is functional within a reasonable time over a 28k modem connection (typical speed in older apartment blocks in the USA) or that a low-bandwidth version of it is available and easily located.
• Cross-browser and operating system compatibility. This is particularly important if your site uses a lot of client-side processing or the latest functionality from a specific browser. If the browser in question is Internet Explorer, you lock a lot of people out of your site.
• Clear indicators of processing - if your site needs to do any potentially lengthy processing (such as live validation of credit card information) you need to make sure it disables as much as possible and shows a clear indicator that it's working or users will assume it isn't and try again - which can cause problems.

Answer 4

I do not think the UI testing is very different: field validation, default values, resizing, scalability, and so on.

You probably need to support more than one brand and version of web browser, and perhaps even some mobile devices. You may want to separate your business logic tests from your browser-level tests so that you do not repeat every test on every browser.

Security testing is different for web applications. This is a big subject, and it helps to have someone who specializes in that kind of thing.

Answer 5

Good answers abound, just wanted to add one more thing to consider for automation - Localizability and how you identify elements is different. In a client app, you identify the element by it's name which is also the value displayed to a user. This means in order to work in localized versions you need to get the correct value from a resource file instead of hard-coding it to the english version. In a web site or web app, you will have identifying attributes on elements such as "id", "name", "class", etc that will not change in different locales and so you do not need to have this dependency on resource files but can still automate in different locales. It's also easy to request an "id" for an element from your developer which can make UI automation simpler.