Here’s the second part of Jigar Patel’s post on mobile web app testing.

Safari and Mozilla Firefox support some great extensions that can make testing your mobile sites on desktop browser much easier. You can get more details here.

Testing mobile applications on the desktop browser, as mentioned, does provide several major advantages. Let me illustrate: From the browser metrics of the application, prepare a list of user agent strings for each browser in your metrics. User agent strings can be easily found through a Google search. From there, setup the Firefox browser to test with mobile application as mentioned in this article. Then, set the user agent sting in Firefox for each device, one by one, and navigate to the sign-in page of the application. See if the site renders the mobile version of the application or the PC version if available. If it does, then we are on the right path, and there is a good chance that real handset seating on the end user hand will redirect to the correct mobile version of the site.

If it renders the PC version of the site, this could be a bug in your application. If so, there are less chances for handsets being supported by your application, provided that it doesn’t render the mobile version of your site. Be sure to document each browser on which this behavior occurs and ask dev to fix it. If it can’t be fixed, then there is less of a chance that the real handset will support it. At this point, we can make the decision to cut down the devices/browser from the metrics which doesn’t redirect to the mobile version of the site. Now you can understand the advantage of testing on a desktop browser, that we can kick out the devices from this analysis before purchasing it to test and hence it will help to reduce the cost!

Finding the device specific bugs: If we found links that are not functional on some devices, then we should check whether it works on the desktop browser or not. If it is reproducible on the desktop browser, then it is not a device-specific bug, but rather a bug in the basic application, irrespective of the device. If a link is functional in the desktop browser and it doesn’t work in the device, then it should be identified as a device specific bug.

Testing at an early stage for the priority devices from the metrics: When the application is in the development phase and is testable, testers should perform a quick test on the top priority devices of the metrics in order to find any rendering or any functional issues in early stage. This way, dev can have enough time to fix them or arrive at a proper decision as whether to support these devices or not. If fixing the bug involves high dev cost, they probably won’t. If this sort of testing doesn’t happen at the early stage, then there is the risk that the application might not work for the key devices. This can lead dev/PM to changes the design, which can further escalate costs.

Usability testing: Usability testing plays an important role for the application to succeed on a wide range of devices. Usability testing should happen as soon as the basic stable for the application is ready. This is also true in order to test whether the application UI is user-friendly or not, or whether some part/functionality of the application is easily discoverable or not. Also, usability studies should be done for the different types of devices, such as touch screen devices, since the user has different experience for the same application on these devices.

So a user may have a good experience on the iPhone, while another might have bad experience on a non –touch screen devices. In this instance, changes to the UI should be considered to improve the experience on the non-touch screen device.

For example, let’s say there is a form with various fields and it is saved by clicking on the save button located at bottom of the screen. For this scenario, someone using iPhone will have no issues to scroll to the bottom to click on the save button, since the iPhone has a good scrolling mechanism. However, the same scenario will give the bad user experience for the non-touch devices users, where scrolling to the bottom of the page is not as easy.

Testing on the emulators: Functional testing on an emulator is a good idea, as it allows us to find the browser/platform specific bugs before the actual device is available. However, emulators are not always reliable since there is the chance that it will produce different results than the real device. Also, when we test on an emulator, we are using a mouse to perform the operations and interact with the application’s UI, which as you know, is much different on the actual device. So when we test on the emulator then we can find functional bugs that are likely to reproduce in the devices. This is a positive sign, but we will be missing out on the actual usability of the application if testing is carried performed exclusively on the emulator.

Performance testing: Performance testing is key criteria for the application success on the market. It may happen that application testing is carried though wi-fi network under which application might perform well, but it also happens that application has the poor performance for the end-user who are accessing site through the mobile carries. If the application performance is poor for the end user he will likely to divert to other services etc. So application must be tested with different devices + carries wise mix depending on the county and region.

***

Editor’s note: If you would like to contribute a post of your own to mobileapptesting.com, email your articles or ideas to me at mikeb@utest.com.