Mobile Applications Testing Cheat Sheet

Nobody likes to step on the same rake. To avoid them at the stage of analyzing and testing the requirements, we created a common cheat sheet. It includes those issues that should ideally be identified and recorded before development. We use it as a checklist, with which we try to delve deeper into the logic of the mobile application and figure out what potential problems the user may have.

The article focuses on testers who are asked to review TK and find inconsistencies in it, and on analysts who, after reading TK, developers often ask questions of the format: “What should happen if ...?”.

So where to start?

General questions on the application

Everything is simple, but it is better never to forget to clarify these issues with project managers and analysts.

1. For which platforms will the application be developed and which OS versions will be supported? You should always remember about the minimum supported OS version. Otherwise, you may find that the functionality does not work for users when the task is already closed.
2. On which devices should I check the app? For example, the application should work both on smartphones and on tablets. Or there should be Apple Watch support.
3. What screen orientation does the app support? Portrait and / or Landskape? Unpleasant moment: if the change of orientation of the screen works well on smartphones, this does not mean that everything will be the same on the tablets.
4. What are the priority devices to watch? On your devices, the application can work perfectly, but at the customer's favorite (insert the Chinese android-smartphone) everything went away ...
5. Should there be a perfect pixel perfect or some errors are allowed? Hi, conformance testing! It is also a good idea to clarify whether the layout should be stretched or should there be different layouts for each screen size?
6. Are there other client applications? For example, there is an admin panel, which suddenly starts deleting or adding elements. Or a web version that already exists in production. The main thing is to find out about it as soon as possible.
7. Are there any external devices that can affect the logic of the mobile application? For example, beacons that send signals to an application, or printers that print information from an application.
8. What is the target audience for the application? All users in the Play Market / AppStore or 50 people in the company of the customer?

Parsing applications on the screens

1. The composition of the screen and the possible actions on it. What are the elements of the screen? What actions can be done? What screen conditions are possible? What are the transitions and which screens they lead? What should be displayed when returning to this screen? Answers to these questions need to be found, and better recorded in the documentation.
2. Interaction with the server on the screen. What requests go on the screen? Understanding what requests to the server are sent on the screen will help identify such requirements that the server cannot implement for one reason or another.
3. Timer activity. For example, important analytics is sent every two minutes or data is being updated.
4. Data caching Loading the same data every time you enter the screen can annoy users. When caching is necessary to think about when to update the information on the screen? When should the cache be cleared?
5. Stubs What is displayed if there is no data? The blank screen is uninformative for the user. A dismounted stub can be a reason for customer dissatisfaction.
6. Behavior in cases of error. What should be displayed if an error occurs? For example, the lack of Internet, server or undocumented error.
7. Slow loading data. What should happen when data is loaded slowly? Loaders, action blocking, custom animations - everything should be thought out.
8. Actions that affect the behavior of other screens. How does the action on one screen affect the behavior of others? Cross-cutting actions - a dangerous thing. Especially if the development and testing goes on the screens or on individual features. Here it is difficult to manage without regression. Therefore, on some projects, before writing test cases, we build an influence matrix for new features.
9. Update screen data. When does the update occur? There are the following options and they can be combined:
   
   • Every time you open the screen (data live only while the user has the screen open).
   • Every time you start the application (data live only while the user is running the application).
   • By pull-to-refresh / by special update button / by timer (data is stored in the device’s local storage and is restored when the application is restarted).

Next, we consider the functionality that is often used in applications.

Navigation in the application

1. Using the side menu. What sections are root? What sections open over root? Is the transition history between root sections reset?
2. With the help of tabbara. Does the tabbar remain on the screen while deepening the navigation inside the section? Does it return to the root screen when re-tapping on a partition?
3. The difference in the transitions between the hardware and software button "Back" in Android.

Localization

Types of supported localization:

1. Texts are sewn inside the application. The user in the settings of the application can set the desired language.
2. Texts depend on the language in the system settings. The language is determined depending on the installed language in the system settings.
3. Texts come from the server. Texts come from the server, and the language depends either on the device settings or on the application settings.

Permissions

1. Request for access to notifications, geolocation, gallery, camera, sms ... Custom screen or just a system alert?
2. User refused to grant access. How does the application behave in this case? Is the access request logic provided?
3. The user has disabled access in the system settings (see paragraph above).

Lists

Often mobile apps include listings. For them, pay attention to the following points:

1. The first loading list. How many items are loaded at a time? What happens when loading? What is the maximum time a list can load?
2. Availability of paging. Is there an element loading at scrolling or is the entire list loaded at once? If there is a load, then it is imperative to check that the elements on the borders do not disappear and are not duplicated.
3. List update (see options above).
4. The presence of sections.
5. The presence of filters / sorting. The filter can be local or server. For lists that are downloaded entirely or are protected within the application, the filters are often local, and testing them does not cause any particular difficulties. For lists with uploads, filters may entail a large number of checks. Similarly for sorting.
6. The composition of each item in the list. There can be both elementary text and entire screens with their own internal logic.
7. Interaction with elements. Adding a new item, deleting, hiding, dragging.
8. Synchronize the list between all devices. As an example, you can synchronize files after changing it on all devices.
9. Saving position scroll. When navigating between sections or returning to the list screen, there can be very important features. For example, if it is a tape post.

Search by list

1. Online / offline search. Offline search is simple. In essence, this is a local filter. For online search, as well as for online filters, there will be much more cases.
2. Character search or search by clicking on the search button. Please note that for a character-by-character search there should be a limit on the number of requests, otherwise the server may start to ignore spam from the application.
3. Clearing the search string.
4. The presence of clues.
5. Availability of query history.

Entry form

1. The list of fields with their description and features.
2. Conditions for storing and resetting data in the fields. When and which fields should keep their values? When to clean?
3. Restrictions on the number and type of characters.
4. Keyboard for entering data on the selected field. Keyboard type: numeric or character. Should the keyboard shift content when opened? Under what conditions should it close?
5. The logic of transitions between fields. By the button “Next”, by “Next” on the keyboard.
6. Validation of incorrectly entered data. Checks on the server or on the client.
7. Auto requests to the server under certain conditions. For example, if the user entered a 6-digit verification code.

Accounts

1. Requirements for registration and authorization of users. Is it possible to register not through the mobile application?
2. Account recovery. For example, if the user forgot the password from the application.
3. Logout Clearing data (in particular, resetting push notification bindings) for an account.
4. SMS authorization. Cases with a phone number, its format, a code of possible countries should be taken into account. Re-sending SMS in case of problems with receipt.
5. Authorization through social networks (see details below in the section “Registration / authorization through social networks”).
6. Authorization on multiple devices simultaneously. Autologout or data synchronization processing.
7. Error handling invalid, outdated account token.
8. Change account data. For example, changing the password.

Registration / authorization through social networks

1. Creating an account at the first authorization through the social network.
2. Uploading data from the social network. Synchronization when they are changed in the social network. For example, the user's first name and surname.
3. Authorization through a mobile application, social network or browser / web view.
4. Barring access to the application to the data from the social network.

Role model

1. Description of the role model. What actions are available for each role?
2. Interaction between representatives of different roles. Interaction between representatives of the same role.
3. Moving users from one role to another. What actions for this must be performed?
4. Estimated percentage of representatives of different roles. What role to pay attention in the first place?

Map

1. First loading map. Which area should boot? Where and on what scale should the map be centered?
2. Loading and drawing elements. Should downloaded items be cached? When should the elements be updated? This moment is very important to consider in order to ensure fast data loading and smooth movements on the map.
3. The logic of the elements on the map. Pins, popapes over pins, cards for pins, building a route.
4. Support for scaling, rotating, tilting the map.
5. Updating geolocation and sending the coordinates of the current location when the application is minimized.

Chats

1. Processing cases, if sending messages was in the absence of an Internet connection or with a bad Internet. Re-send messages.
2. Group chats. The logic of adding / removing interlocutors in the chat. The maximum number of interlocutors.
3. Status of sending / receiving messages. It is better to immediately pay attention to group chats. What is considered a read message in group chats?
4. Uploading chat history (see questions for lists).
5. Presence of additional features : deleting messages, displaying “<Insert_name> prints”, preview of sent files, message forwarding.
6. The mechanism of the chat. For example, you need to understand how chat works on sockets in order to locate bugs during testing and determine which side is the problem.

Sending files to the server and downloading to the device

1. File format What file formats should the system handle and which ones to generate an error?
2. Resume interrupted send / download. Automatic or after user confirmation?
3. Maximum number of files sent / uploaded.
4. Lack of memory on the device to download the file. In practice, there have been cases when there is not enough memory to not just download the file, but even to write to the database. Such problems had to be handled.
5. Cancel sending / downloading file.
6. Replacing a file with one another.
7. Downloading to external memory SD Card.
8. Downloading in the background when the application is minimized.

External devices

1. Connect / disconnect device. The communication channel through which it interacts with the application (Wi-Fi / Bluetooth).
2. The influence of an external device on the application logic.
3. External device configuration. Are there any systems that administer the external device?
4. The maximum distance at which interaction occurs.
5. Signal strength / power. Find out what these parameters may depend on? For example, if a beacon is hidden in a metal can, then the chances of losing its signal increase dramatically.
6. Connect multiple external devices simultaneously. For example, switching from one device to another can lead to curious cases.
7. Connecting to an external device when the application is minimized / when the screen is locked.

Audio player / video player

1. Supported file formats.
2. Caching playable content. Be sure to understand how much data needs to be cached for user convenience.
3. Playing in the background. Is it necessary to load data when the application is minimized?
4. Notification player in the system curtain.
5. Integration with Bluetooth headset, CarPlay and with other external systems.

Payment by credit card

1. Linking to a profile and deleting a bank card. Is there a test withdrawal of the minimum amount? For example, 1 ruble, which will then return to the account.
2. Payment tied card. For example, whether there will be a repeated request for SMS confirmation at subsequent payments?
3. Error handling when trying to bind / pay by card.
4. Synchronization of the list of cards in the presence of several clients in the system. For example, there is a web version and there is an iOS version.
5. Scan through the camera and recognize the card number.

Time, calendar, timer

1. Calendar / time. Does the application logic incorrectly set the date and time? Can I choose a period? What is the range of acceptable values?
2. Timer. Local / server? How does the server timer synchronize? For example, in Android, an application may not be guided by the time set on the device, but by the time it starts the device. No matter how the user translates the clock in the system settings, the timer will not be lost.

Notifications

1. Type of notifications. Are there notifications for certain events that are protected in the application? Or push notifications sent by the server?
2. Actions that are available with notifications. What happens if you go through the notification? Close her? What if the notification is out of date and unavailable?
3. Binding notifications to a specific account. What actions indicate to the server that one user exited and logged in another?

Of course, not all of the possible functionality of mobile applications is covered in this cheat sheet. Here it serves as a starting point for the start of test analysis. Share your comments or cheat sheets in the comments that help you in testing requirements.