iOS Exploratory Testing Techniques

Testing iOS applications presents a unique challenge to both developers and testers. The environment that an iOS application exists in is _unpredictable_ and _unforgiving_. This means that an iOS application should be _robust_ and _tolerant_ of such an environment–because it doesn’t have any other choice.

During my time as the de-facto “iOS guy” at Atomic Object I’ve learned a set of exploratory testing techniques that I use when testing an application. Taking the time to do this has helped us avoid both embarrassment and unhappy users.

h1. The Techniques

*Turn Airplane Mode ON*

This is a well known technique that Apple employs before approving an application. The application doesn’t necessarily have to provide the same experience in airplane mode. However, the application shouldn’t _crash_ when it is opened. If possible, it should also inform the user that it is operating in a less-than-ideal environment.

*Use the Edge Network*

The Edge Network is a slow, packet dropping, latency ridden experience. If there are any bad techniques being used while your application is retrieving data, this should thrust them into the forefront.

These bad techniques include:

* Blocking (hanging) while the application retrieves data
* Not providing an intermediate “loading” UI
* Not turning on the “network activity indicator”

A slow network stresses a user out and during these times they are more likely to ‘abuse’ the application. For instance, they may become tired of waiting for a particular screen to load so they will tap out of that screen and then re-enter it over and over again until they’re sufficiently satisfied that it isn’t your application causing the problem.

*Click the Home Button*

The home button is analogous to the “Save” button to iOS users, so it is important to test that an application saves any relevant information when the user decides to exit the application. Generally, users also expect that they will return to the last place they were in the application when they reopen it.

*Toggle the In-Call Status Bar*

When the in-call status bar is being shown it _reduces_ the available screen real estate that an application can utilize. If an application, like this “one”:https://spin.atomicobject.com/wp-content/uploads/facebook_in_call_status_bar.png, assumes that the screen real estate is constant then it is going to find its user interfaces in a sad state of affairs. I would recommend occasionally going through the entire application with the in-call status bar on.

*Use the application in Landscape mode*

If an application or screen supports landscape mode then make sure it is _tested_ in landscape mode. This may seem obvious. However, a developer could make what appears to be a small and innocuous change to a UI and not test it. Consequently the application behaves poorly in that mode.

*Cause a memory warning or two*

On iOS devices, when memory is running low, it sends “memory warnings” to the application. The application will then unload any views that aren’t being shown. When the user returns to those views the application will reload that view. For a developer, it is easy to mistakenly load and unload a view incorrectly, so it is important that the app is exercised in low memory situations. The consequences of not properly loading and unloading a view range from half-rendered UIs to total UI loss where the user can’t do _anything_ with the application.

The easiest way to cause a memory warning is via the iOS Simulator. A memory warning can be simulated by selecting “Simulate Memory Warning” under the Hardware menu. However, if you do not have the simulator available the best way to cause a memory warning is to navigate as deep as you can into the application, press the home button, use another app, and then reopen the application.

*Run it on legacy devices*

Legacy–2G, 3G, and 3GS–devices are slower and have lower screen resolutions. Testing an app on a legacy device will illuminate any issues with regard to speed, memory, and artwork decisions.

A legacy device has significantly less memory and CPU power which means that your application has even fewer resources to work with. Running the application on a legacy device will highlight any areas of the application that utilize memory inefficiently (causing the app to crash) or cause the application to run slowly (choppy animations, unresponsive).

Because a legacy device has _half_ the resolution of a Retina display, some font and graphic choices made for the Retina device may not work well on a legacy device. An 11-point font on a legacy device does not anti-alias as well on a legacy display, for instance.

*Install the new application on top of a version currently in the App Store*

This is a very important test to perform if another version of an application exists on the App Store. The application’s internal structure in the new version may have changed enough that it is _incompatible_ with an older version. The application is responsible for transitioning any data or state on the old application to the new application without losing important data or crashing.

I cannot count the number of times that I’ve had to remove the old version of an application and install the new version before it would work again.

*Change the Timezone and the Date*

Any application that displays a date or makes decisions based on a date should be tested in the timezones the application will be used in most. I would also take the time to exercise the application in both Standard Time and Daylight Savings Time. Time is a strange and complex entity that can bring what appears to be a well-written application to its knees.