Checklist to Rock iOS App Testing. Part II
What’s up, people? We are in the second part of article reminding you about top 7 must have checkpoints crucial for iOS apps testing. Here’s link to the first part of the article.
To keep in head all of the necessary things we need to test, let's use the informative mind map we posted in the previous part:
#4. Device Resources.
Be sure to test following situations:
- Space overload during installation or iOS application operation:
App shouldn’t crash, and all the necessary information should be displayed in notification.
- Insufficient memory to run the system with active or running in the background app: all data obtained by the product must be saved (unless otherwise assumed by app’s functionality, for example, data synchronizing with the server).
Such situations are common, and if errors are not identified in pre-release testing, then we can only guess on the extent of further problems.
Let’s imagine this: you are in a business or vacation trip in new, unknown city. You are downloading a city guide or navigator via Wi-Fi, but the app doesn’t want to help you at all. Program crashes with frightening messages instead of showing informative kind reminders on insufficient memory for the correct work. If user is completely aware of what’s going on with his iPhone’s memory space, he’ll just delete some old games and successfully re-launch this navigator or city guide.
#5. Battery Discharge.
- Check that the low battery notification appears:
Performance testing is necessary, because smartphone battery charge runs down pretty fast. Your active iPhone app mustn’t affect the low battery notification somehow. All elements of the notification should display correctly.
- Check that app shuts down correctly at complete battery discharge:
It’s easy to imagine the situation when iPhone completely discharges. And what user surely doesn’t find out after re-launching your app is unsaved changes, disappeared personal data, or even full reset of a game progress. Would you enjoy starting over from 1st level or you’ll just delete the app from device? Answer is obvious. Performance checking is the key. And don’t forget that after the shutdown app’s logs shouldn’t contain any errors.
#6. Working with interrupts.
Do we even remember what smartphone is for, after all? Sometimes this magic box is for calling, so there is a probability that user will get a call or text while enjoying your app. When testing iPhone apps, this situation should be checked on various forms of the application. In addition, the form for incoming calls or texts should be available when you open the application; all the elements of both the program and form must be displayed correctly and don’t overlap each other. Speaking of interactive apps, they should switch to standby mode for a call, and then correctly resume their operation.
#7. Active app minimizing / restoring.
This is crucial for iOS games. Correct program suspending when minimizing the app and later operation resuming when restoring the application is essential. Indeed, when playing on the way to work or home, you’ll sooner or later get a reason to minimize the game, and if on restoring all those precious victories will just disappear…let’s say it would be pretty disappointing.
In the current extremely competitive app market, many products are released in no time, trying to earn their place in the sun and make tons of money. However, we suggest remembering about the clients’ loyalty, reputation, and trustworthy name. Critical errors in the product may lead to different consequences from simple uninstall of your app by unhappy user to lawsuits due to security gaps entailed stolen personal data or money from accounts.