Common Bugs When Testing iOS Apps

The bugs we’ve encountered ranged from app specific usability issues to general issues common amongst many apps. Today, we want to highlight 5 issues that we’ve encountered repeatedly, using some of the most popular apps as examples. The list below is presented in no particular order.

1. Handling Bad Network Connections

iOS devices are inherently mobile, so apps cannot assume permanent, fast connections to the internet. Tasks requiring network connections should generally be asynchronous and notify the user if they fail due to lack of connectivity. Facebook Messenger and iOS FaceTime handles this nicely. 

In Facebook Messenger, a warning message is displayed prominently, indicating that Internet connection is required for the app to function.

In FaceTime, an alert is displayed with buttons that take the user directly to network settings.

On the other hand, Vine and Instagram do not handle this well.

In Vine, users see a sad face and posts simply do not load. There’s no indication that this is caused by network connectivity.

Instagram shows a large reload button on images that cannot load. This button has no effect while network is off.

2. Handling Chinese (extended) Keyboard

iOS has a number of international keyboards built in. While most of these keyboards are of the same size, a few keyboards have extended sections. The Chinese Pinyin keyboard is an example of the extended keyboard. Apps should not assume a fixed keyboard size and should adjust their content appropriately.

The Google+ app, as shown above, has a small button above the normal keyboard that hides the keyboard when pressed.

However, when the Chinese keyboard is used, the extended keyboard covers most of the button, rendering it useless.

Using the device in landscape mode exacerbates the problem. In Twitter, the extended keyboard, custom buttons, navigation bar, and status bar combined take up almost the entire screen, leaving no room to display the input text field.

3. Handling Privacy Settings

iOS privacy settings control third party app access to photos, locations, and contacts. Apps needing access to these assets need to handle cases when access has been denied either inside the app or outside through system settings. A great way to handle this is to let the users know about the necessary permissions and give them instructions on how to turn them on.

A good example of how to handle this is the Facebook app. When it lacks permission to access location, it shows a clear message with step-by-step instructions for users on how to grant access.

On the other hand, when Vine lacks permission to access location, it gets stuck searching for nearby places with no indication of what’s wrong.

4. Validating User Input

Many apps allow users to input username, birthdate, or other account information. Basic input validation should be implemented, and if the user’s input is invalid, a clear explanation should be presented.

Skype does not validate user’s birthdate, so a completely bogus date can be entered.

Path has very few restrictions for usernames. In the screenshot above, the username is set to a large number of blank spaces followed by a period. Path does not allow usernames to contain only blank spaces and will fail silently (i.e. it does not save the username and shows no explanation). 

5. Handling Simultaneous Button Presses

iOS devices support multi-touch and apps should properly handle cases when users intentionally or accidentally touch multiple buttons at the same time.

In Pinterest, tapping ‘Pin it’ and ‘Send’ at the same time when viewing a pin will cause the app to enter a bad state.

Conclusion

As we’ve illustrated above, common issues can be found even in some of the most popular and mature apps. By sharing experiences we gained from testing, we hope to help improve apps built by our readers. There’s a lot more we’d like to share in future posts. If you have any thoughts or questions regarding testing, don’t hesitate to contact us at support@rultech.com

Rultech Blog - Wordpress

Rultech Blog - Blogspot

Rultech Knowledge Base - Knowledge Base

Pro!deaClub Blog - Blog

Pro!deaClub - Blogspot 

Testing on Android : Unit Tests

JUnit Tests

There's no reason you can't use normal JUnit 4 testing for Android applications... as long as you stay away from anything Android.

Normally you compile against the SDK's android.jar, which contains nothing but stubbed methods that throw exceptions when run.  When you actually upload your APK to a device, it uses the device's implementations of all those stubs.  As a result, when running normal unit tests in your IDE, you get no access to those framework implementations (instead receiving mountains of exceptions).  This is not a big deal if you're testing some simple functionality that doesn't touch Android itself.

Pros:

            Fast and easy

Cons:

            Cannot use any Android framework classes

The Android Testing Framework

The Android testing framework is the official method of unit testing on Android.  It loads your application onto a device, then runs JUnit-based test suites.  Since it runs on the actual OS you can use the Android framework as you normally would in your application and can conduct a series of realistic tests that way.

Ostensibly the testing framework is unit testing, but the slowness of having to fully compile and upload your app onto a device before executing any tests makes testing slow.  Plus, you have to make sure you've got a device attached or an emulator running.  As a result, I might consider the testing framework for semi-regular tests (e.g., whenever you push a new commit, or nightly tests) but I would have trouble using them while actively developing.

Pros:

            Access to the Android framework

Cons:

            Slow

            Requires attached device or running emulator

            Uses JUnit 3 (instead of the newer JUnit 4)

Robolectric

Robolectric is a project that unifies the speed of unit testing with the ability to access the Android framework.  It does this by implementing all those stubs with mocked classes.

Having tried it out, it is lightning fast and works as expected.  I'm also impressed with the amount of active development on it - this is a rapidly improving framework.  However, the active development does take a toll; documentation is a bit lacking, plus some new versions of Robolectric break things in previous versions.  Plus, it can't mock everything - for example, inter-app communication - since it's not on an actual Android OS.  That said, the benefits here far outweigh the negatives when it comes to unit testing Android.

Pros:

            Fast

            Can access mocked Android framework

            Actively developed

Cons:

            Not the true Android framework

            Not everything is mocked

            Lacking documentation

Rultech Blog - Wordpress

Rultech Blog - Blogspot

Rultech Knowledge Base - Knowledge Base

Pro!deaClub Blog - Blog

Pro!deaClub - Blogspot