TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: A Primer in Testing Mobile Phone Applications


Viewing Item 1 of 511


A StickyMinds.com Original
Article Picture
A Primer in Testing Mobile Phone Applications

By Julian Harty

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: It took eighteen months for Julian Harty to overcome the various challenges of testing mobile wireless applications. In turn, he has learned some valuable lessons that he wants to share with you in this week's column.


Seapine
Eighteen months ago, I started learning about the joys and challenges of testing mobile wireless applications. This article is dedicated to the various tips and tricks I've collected along the way that may help you become productive much more quickly.

Reduce Setup Time
Find ways to reduce the time required to configure the phone, install the software, and learn about the underlying connectivity. For example:
  • Your carrier or handset manufacturer may enable you to download the Internet settings to your phone rather than trying to discover and then manually key in the obscure settings.
  • Often the software needs to be installed from a Web site. Use text messages to send long Web addresses. Keying a URL can take several minutes and one false move may mean starting again!
  • Learn how to use a computer to install the software. Many manufacturers provide free software that will enable you to add and remove software applications relatively painlessly from a computer.
Figure Out Connectivity
Mobile connectivity remains a challenge. But remember, a connection relies on at least four elements:
    1. Configuration of the phone
    2. The service provided by the carrier (and paid for by the user)
    3. The connectivity between the carrier’s wireless network and the Internet (where gateways can filter, modify, convert, or even block communications for various reasons)
    4. And the rest of the connection to the Web/application server, which may include more gateways, firewalls, etc.

Phones provided by carriers may have the network settings preconfigured. If you have to configure these settings, you will need to learn about Access Point Names (APN), WAP gateway settings, and, possibly, login details for the service provided by the carrier.

Understand Your Data Plan
Carriers may offer a range of data services, from very limited access to a small list of approved Web sites (called a walled garden in the industry) to full "Internet" access that may even allow Voice over IP, video streaming, etc. Some carriers provide clear information on which services are available for each price plan; for others, you may have to research what services and Web addresses work reliably.

Check how much you pay for data before embarking on data-intensive applications. I had a monthly data bill that was more than $300—even though I didn't use any of the installed applications on my phone during that time. However, one of the applications polled its server in the background while I was abroad. At $16/MB transferred, it was an expensive lesson to learn!

Understand the Impact of Transcoders
Transcoders help make a majority of the Internet more accessible to mobile devices; however, sometimes transcoders have unexpected consequences for the application you want to test. For browser-based Web content, these problems are often visible and therefore relatively easy to discover. However, for custom applications written to run on the mobile devices, transcoders may adversely affect the data communications and cause the application to report errors or even crash without telling you what's going wrong.

Find Ways to Understand and Simplify Problems
I have found diagnostic client software and diagnostic Web servers particularly useful for discovering and debugging issues with transcoders. Both the client and the server are designed to report the information that is sent and received. Find out whether the content is expected to be transcoded, and if so, how. If not, the data sent by one end should be received unchanged at the destination and vice-versa. The diagnostic software recorded all the data and made problems easier to detect.

If possible, run your diagnostic software on a personal computer with a wireless data modem to debug transcoder or carrier network issues. Generally this is much easier than trying to debug client software on a phone.

Use Complimentary Tools
Find complimentary ways to test using Web browsers for Web-based mobile sites. Firefox has numerous free plug-ins that emulate a phone’s Web browser and make manual testing easier. I use the following: WMLBrowser, Web Developer, User Agent Switcher, and Modify Headers.

Reduce the Number of Combinations
As there are thousands of permutations of phones and carriers, pick an exemplary subset of phones to test with. For instance, when testing Java software (written in Java 2 Micro Edition), I test on classes of phones that include: Nokia Series 60 second and third editions; Sony Ericsson’s Java Platform 6, 7, and 8 phones; and BlackBerry models based on the keyboard layout and operating system version.

Pick popular phones and phones with large and small screens and a variety of keyboards, including: T9 (where the alphabet is split across the numeric keys 2 to 9), QWERY, and other unusual keyboard layouts. Over time you may collect "interesting" phones that help expose application flaws. For example, one of my phone's core software has been highly customized by the carrier and has exposed limitations in applications that appear very quickly. By finding and reporting these issues early, the developers were able to revise their application software so it was much more flexible and robust.

Here's a site that details another way to classify your phones based on the operating system and UI: Using a Device Hierarchy.

Take Good Notes
Remember to use the recording tools, now! When you find a possible problem during testing, start by recording immediately what you see, as some messages are transitory and clear within a short period. Find ways to record UI issues, on-screen messages, etc. I use:
  • A good-quality, inexpensive digital camera with a sturdy, close-up stand
  • Free software that takes screenshots on certain types of phones, such as fexplorer, and similar tools from Research-In-Motion (called JavaLoader) or from shareware vendors
Now document what relevant events preceded the problem, including things like signal strength, battery level, as well as actions you performed. Try to reproduce the problem on that device. Before considering the bug final, try similar and different devices, different carriers, etc. While this work may take anywhere from minutes to a few hours, the answers may help the developer hone in on the problem much more accurately and quickly. Be practical, and don't forget to ask the developer for help and advice before you expend too much effort.

Practice Makes Perfect
Testing mobile wireless applications effectively takes time and practice, particularly if you are new to the field. I hope you will find some of these tips useful. Get comfortable configuring and using a variety of phones, and you'll soon be much more capable and productive as a tester of mobile wireless applications.

The next lesson is how to automate some of the testing—a great subject with plenty of scope for you to develop your skills and make a big difference in the industry!


About the Author
Julian Harty currently works as a software tester at Google on some really cool and innovative projects, which hopefully many of you will find useful and fun. He has over twenty years of experience in computing and is passionate about helping to make software work properly. He is also an international speaker and author.

Back to Top
 

StickyMinds.com Weekly Column From 12/31/2007 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Samuli Lahnamäki 5/8/2008

One addition which makes testing with phones sometimes much faster is to use Bluetooth (or some other external) -keyboard to write long or difficult texts many times. Very uselful sometimes when testing has to be done in actual device.


 
 
Comment:    
by Brad Wisdom 1/3/2008

deviceanywhere.com is a great service at a competitive price. we recently used it to test broswer based software and it is great for support related calls and trying to reproduce problems customers are experiencing.

Author's Response:
1/7/2008    
Brad, thank you. I've used device anywhere as well and agree it's a useful service to augment other testing. There are several similar services, including one from Nokia called Remote Device Access http://www.forum.nokia.com/main/technical_services/testing/rda_introduction.html

This includes a range of current and recent Nokia models. AFAIK people can join the forum free-of-charge which includes limited access to the service. Nokia also offer paid-for membership which offers more access and additional features.


 
 
Comment:    
by Faisal Feroz 1/2/2008

Really nice article. It is really hard to get hold of handsets and go through all the configurations and manual testing. There is service available on www.deviceanywhere.com whcih makes this job a a lot easier by giving access to so many handsets out there in real networks. Above all they also provide toosl for automating tests. Here are the excrepts fom their site:

"DeviceAnywhere solves one of the biggest challenges facing mobile app/content developers - access to handsets in target carrier networks. DeviceAnywhere is a revolutionary online service that provides access to hundreds of real handsets, on live worldwide networks,...Read On

Author's Response:
1/7/2008    
Thanks for adding the comment, I expect some readers will find the service useful.



 
 
Comment:    
by Jarrod Edwards 1/1/2008

Interesting article, I'm currently drafting a piece on the usability testing of hand-held devices in a wireless environment with a view from the retail perspective. Would anyone have any hints or tips on other authors to review their papers?
Much Thanks, Jarrod.

Author's Response:
1/7/2008    
Jarrod,
Glad you liked the article.

I don't quite understand your question "Would anyone have any hints or tips on other authors to review their papers?" - are you asking me to recommend people to review a paper written by you? by other people? or something entirely different?

In terms of your paper it sounds interesting. I have some thoughts on the sort of factors I'd like to be considered in terms of testing a mobile application in a retail environment, such as:
1. what are the typical working conditions e.g. do users need to handle food or other sensitive items where they may need to use gloves?
2. what forms does the input take e.g. can they provide spoken input? If so, what are the ambient noise conditions, etc?
3. Will they be handling sensitive customer data?
4. What types of tasks will the application support e.g. would they be used to record live surveys or questionnaires where a customer is being interviewed by an employee? Here I'd consider things like the amount and richness of data that needs to be entered and whether its possible and practical to have multiple-choice options, etc.



 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


ThoughtWorks

Rally Software




Agile Development Practices 

STARWEST