Mobile Device Applications Testing Tips - User Interface Testing

The first area to explore in your test plan is the user interface. While smart phone applications are relatively new, there are already accepted guidelines for look and feel and overall behavior. It is your job as the tester to confirm that your application follows these principles. Note that this paper does not cover Usability Testing for mobile devices, which is critical to creating a compelling, usable mobile application. Usability testing and other user-centered design principles will be

covered in a future paper.

Comparing your application with native applications

If you are not already a regular user of the device you are testing with, the first thing you should do is familiarize yourself with the device and some of its common native  applications such as its Phone, Email, Camera, Contacts, and Calendar programs, etc. These are applications that device users see everyday so it is important that your application has a similar look and feel.

As you are exploring, take note of things like:

1. Overall color scheme/theme of the device. For example, Blackberry has several themes that differ even between its own models.

2. Style and color of icons. For example, Android has well-defined icon design guidelines.

3. Progress indicators when pages are loading.

4. Menus. How they are invoked and typical items they contain.

5. Overall responsiveness of applications on this device.

Screen orientation/resolution

If your application is supported on various devices that have different screen resolutions, make sure you test early with the device that has the smallest screen. This will flush out any layout problems where the design is simply too large to fit on the necessary screen size. Of course, don’t forget to do regression testing of any subsequent layout changes to make sure your application still looks good on larger screen sizes as well.  If your device supports screen orientation changes, like the iPhone and some Android, Blackberry and Windows Mobile models do, be sure to include lots of testing where you rotate the device from portrait to landscape display, and vice versa, on all of the pages within your application. This re-orientation completely changes the screen size so layouts may no longer display as intended. Also, it is easy for developers to leave uncaught exceptions around screen re-orientation events that could cause the application to crash, especially if you do this re-orientation back and forth quickly before the previous orientation change gets a chance to fully complete. It is also important to test input reactions when the screen orientation is changed. Try using the soft keyboard while changing the orientation repeatedly. On Windows Mobile and some Android devices, a change in orientation is automatically triggered by extending the slide-out keyboard. Attempt this repeatedly and quickly to see if the rapid changes in orientation have a negative effect on the application.

Touch screens

If your device has a touch screen, then there are numerous extra things to consider, such as the following:

1. Multi-touch vs. single touch screens – If your device and application support multi-touch features, like the pinch-to-zoom effect on iPhone, be sure to include lots of test cases involving touching the screen in more than one place simultaneously, especially while typing on the soft keyboard.

2. Long touch vs. short touch – While there is usually no concept of a double-click on touch screen devices (although there could be if specifically implemented in your application), some, like the Android smart phones, distinguish between long touches and short touches: pressing and holding an item will bring up a context menu in the middle of the screen, while short-clicking the same item will automatically perform the first action in that context menu. All Windows Mobile touch screen enabled devices also use long touch vs. short touch for different reasons: be it to open context menus in certain applications; or to enable a secondary function of a button such as selecting Pause, Wait, and the international dialer symbol when holding down the “*” button in the dialer.

3. Button size and position – Ensure that buttons and icons are large enough and far enough from the edges of the screen to be easily clicked by a large fingertip. If the button is not large enough for a finger to press, such as the Close button on a Windows Mobile device application, verify that a stylus can be used to access and operate such buttons.

4. Workflow – Applications should ideally make use of wizards with multiple choice selections like radio buttons and checkboxes to minimize the amount of typing the user needs to do, which can be excessively time-consuming.

5. Other input methods! interactions – In most cases your touch screen device will also have other input methods such as a trackball or hard keyboard. It is important to ensure that virtually simultaneous inputs from all the methods do not interfere with each other. For example, on Android a GUI item may lose its current selected state if you select it by touching the screen, but then switch to using the trackball to navigate.

If you want more touch screen testing details, please see our 3-part blog series5 on this topic as well.

Trackballs, track wheels, and touchpad

If your device doesn’t have a touch screen, it is even more important to verify that screen navigation is as painless as possible for the user. In these cases, the user may rely on a trackball, track wheel, or touchpad to move from object to object. Even if your device does have a touch screen, don’t forget that some users will still want to use the trackball so it’s important to ensure all screen items can be reached with trackball navigation as well. This is an area often overlooked by development teams where inconsistencies can arise.

Soft keyboards

If your device has one, pay special attention to how the user must interact with the soft keyboard. There are often various special cases and corner cases that are overlooked by development, but important to end users.

1. Does the soft keyboard automatically appear if the user’s main action is to enter some text?

2. Does the first layer of the soft keyboard include shortcut “@” and “.com” keys if the highlighted field is for entering email addresses? (For example on Android, developers can easily enable this by using the textEmailAddress attribute).

3. Does a long touch on a soft character key bring up several different character choices for that input, such as different accents and symbols on a Windows Mobile device when entering contact information?

4. Can the soft keyboard be dismissed and re-displayed easily?

5. Can the soft and hard keyboards be used interchangeably (if the device has both)?

6. Do soft keyboard characters entered in password fields only show up as ****?

Hard keys

Be sure to include a lot of testing around the use of the device!s available hard keys such as Start, Home, Menu, and Back. In order for the user to have a great experience, these should all interact with your application similarly to how they interact with the device’s native applications. For example, Blackberry users expect to make extensive use of their hard Menu key for options, as opposed to clicking buttons or making selections on the screen itself. Android users will expect a short-click on their hard Menu key to either lead to the application’s Settings page or pop up a context specific menu, while a long-click should expose the soft keyboard. Also note that some HTC Windows Mobile devices have a hard zoom bar below the screen that when slid, should zoom in or out on certain visual aspects of the application.

Shortcuts

Find out if there are any expected shortcuts common for your device and test their use within your application. For example, you can find a great list of Blackberry keyboard shortcuts on the web7.

On Windows Mobile devices, the Start Menu will have a list of programs installed that can be launched with a single touch. Newer HTC Windows Mobile devices have the Touch Flo screen appear when you launch the Start Menu, which will display a user editable list of shortcuts to applications. Testing to make sure your application can be correctly added to and, more importantly, launched from this list is critical.