There are numerous other factors that are external to your application itself, but inherent to the mobile device that the application will run on. It is important to also test how these factors may influence your application.
Network connections
Since your application is going to be used on devices in various locations with various network connection speeds, it is important to plan testing coverage for the following scenarios:
1. Only Wi-Fi connection
2. Only 3G connection
3. Only 2G connection
4. With no SIM card in the device
5. In Airplane mode (or all connections disabled)
6. Using the network through a USB connection to a PC
7. And most interestingly, test intermittent network scenarios that a user might encounter in the real world:
a. Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
b. Ride in an elevator or on a train where the network connection may go up and down
c. No network connection available at all
SD card interactions
If your application can potentially store or retrieve items on the device’s SD card, then it is important to test the application’s behavior when there is an SD card present or not. At a minimum, the application should provide user-friendly error messages when a function cannot be performed due to a missing SD card. Also consider removing the SD card in mid-operation (particularly on devices where it can be easily removed without taking the back off of the device).
Phone calls and other interruptions
If the mobile device you're testing with is also capable of making and receiving phone calls, be sure to test the following scenarios to see how your application reacts before, during, and after the call:
1. Your application is interrupted by an incoming call, originator hangs up the call
2. Your application is interrupted by an incoming call, terminator hangs up the call
3. Your application is interrupted by placing an outgoing call, originator hangs up the call
4. Your application is interrupted by placing an outgoing call, terminator hangs up the call
Also take into consideration such interruptions as:
1. Text messages
2. Voicemail notifications
3. Calendar events
4. Social media notifications (Facebook, Twitter, etc)
5. Alarm clocks
6. Low battery notifications
Any of the above could have an impact on the functionality or overall responsiveness of your application.
Device options
Explore your device’s options, and change settings such as the following to see how they affect your application:
1. Sound profiles – On phone you can change the “Profiles (Ring Tones)” setting to options like Loud, Quiet, Vibrate, Phone Only, or Off. Does your application respect the device’s set profile?
2. Device password/unlock pattern – You may be able to configure this as a requirement during application installation (for example setting Password option “Prompt on Application Install” to Yes). Does your application still install correctly when prompted for password/unlock pattern?
3. Font – How does choosing a different font family, size, or style affect the appearance and usability of your application?
4. Screen timeout/Auto on, off – Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.
5. Screen orientation – You may be able to enable/disable automatic orientation switches when the device is rotated, on some Android devices for example. Does your application respect this setting? (However, also keep in mind that the application code can lock a screen to a particular orientation so if you find an issue here it might actually be design intent).
6. Connections – Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Mobile devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your application’s behavior?
No comments:
Post a Comment