CHECKLIST MOBILE APP TESTEN

Table of contents
INTRODUCTION...................................................................................2
DEVICE SPECIFIC CHECKS........................................................................3
NETWORK SPECIFIC CHECKS....................................................................5
APP SPECIFIC CHECKS............................................................................6
APP USER INTERFACE CHECKS..................................................................7
STORE SPECIFIC CHECKS.........................................................................9
TERMONOLOGY..................................................................................13
DOCUMENTATION................................................................................14
INTRODUCTION

This checklist is specifically designed to test the characteristics of a mobile app. Obviously,
it tests only generic app characteristics and not the functionality of the app. For this a
separate test approach and test script must be created.
The checklist is split into different fields:

Device specific characteristics. These are characteristics that are related to the
device on which the app is installed.
Network specific checks
App checks. These are things to check that have to do with functionality that is
frequently used in an app.
App User interface checks.

The checks dont have to be executed in the order they are given.
DEVICE SPECIFIC CHECKS

# Description Responsible Remarks

TE?
1.1 Can the app be installed on the device? Sarah
1.2 Does the app behave as designed/desired if Sarah
there is an incoming call?
1.3 Does the app behave as designed/desired if Sarah
there is an incoming SMS?
1.4 Does the app behave as designed/desired if Sarah
the charger is connected?
1.5 Does the app behave as designed/desired if Sarah
the charger is disconnected?
1.6 Does the app behave as designed/desired if Sarah
the device goes to sleeping mode
1.7 Does the app behave as designed/desired if Sarah
the device resumes from sleeping mode
1.8 Does the app behave as designed/desired if Sarah
the device resumes from lock screen?
1.9 Does the app behave as designed/desired if Sarah
the device is tilted?
1.10 Does the app behave as designed/desired if Sarah
the device is shaken?
1.11 Does the app behave as designed/desired if Sarah
a local message is coming from another
app (think of: calendar reminders, to-do
task etc.).
1.12 Does the app behave as designed/desired if Sarah
a push message is coming from another
app (think of: twitter mentions, whatsapp
message, wordfeud invitation, etc).
1.13 Does the app interact with the GPS sensor Sarah
correctly (switch on/off, retrieve GPS data)?
1.14 Is the functionality of all the buttons or keys Sarah
on the device defined for this app?
1.15 Verify that buttons or keys which have no Sarah
defined function have no unexpected
behaviour on the app when activating.
1.16 In case theres a true back button Joyce
available on the device does the back
button take the user to the previous screen?
1.17 In case theres a true menu button Joyce
available on the device, does the menu
button show the apps menu?
1.18 In case theres a true home button Joyce
available on the device, does the home
button get the user back to the home screen
of the device?
1.19 In case theres a true search button Joyce
available on the device, does this get the
user to some form of search within the app?
1.20 Does the app behave as designed/desired if Joyce
the Battery low message is pushed
1.21 Does the app behave as designed/desired if Joyce
the sound on the device is turned off?
1.22 Does the app behave as designed/desired if Joyce
the device is in airplane mode?
1.23 Can the app be de-installed from the Joyce
device?
1.24 Does the application function as expected Joyce
after re-installation?
1.25 Can the app be found in the app store? Joyce
(Check after go-live)
1.26 Can the app switch to different apps on the Joyce
device through multitasking as
designed/desired?
1.27 Are all touch screen positions (buttons) Joyce
working when a screen protector is used.
NETWORK SPECIFIC CHECKS

# Description Responsible Remarks

TE?
2.1 Does the app behave according to Joyce
# specification if connected to the internet
through Wi-Fi?
2.2 Does the app behave according to Joyce
specification if connected to the internet
through 3G?
2.3 Does the app behave according to Joyce
specification if connected to the internet
through 2G?
2.4 Does the app behave according to Madhavan
specification of the app is out of network
reach?
2.5 Does the app resume working when it gets Madhavan
back into network reach from outside
reach of the network?
2.6 Update transactions are processed correctly Madhavan
after re-establishing connection.
2.7 Does the app still work correctly when Madhavan
tethering or otherwise connected to
another device
2.8 What happens if the app switches between Madhavan
networks (Wi-Fi, 3G, 2G)
2.9 Does the app use standard network ports Madhavan
(Mail: 25, 143, 465, 993 or 995 HTTP: 80
or 443 SFTP: 22) to connect to remote
services, as some providers block certain
ports.
APP SPECIFIC CHECKS

# Description Responsible TE? Remarks

3.1 Has the app been tested on different type of Madhavan
devices and different versions of OS?
3.2 Stability check: if the app has a list (for Madhavan
instance of pictures) in it, try scrolling
through it at high speed.
3.3 Stability check: if the app has a list (for Madhavan
instance of pictures) in it, try scrolling to
before the first picture or behind the last
picture.
3.4 Is downloading of the app prevented in case Madhavan
its bigger than the OS allows downloading
when connected to cellular networks.
3.5 Integration: does the app connect correctly Madhavan
to the different social networks (LinkedIn,
twitter, facebook, etc).
3.6 The app does not interfere with other apps Madhavan
when in background/multitasking mode
(using GPS, playing music, etc.).
3.7 Can the user print from the app (if Madhavan
applicable)
3.8 The search option in the app displays Madhavan
relevant results
3.9 Verify most common gestures used to Madhavan
control the app.
3.10 What happens if you select different options Kilim
at the same time (undesired multitouch,
for example select two contacts from
the phone book at the same time).
3.11 App name should be self explanatory Kilim
3.12 Does the app limit or clean the amount of Kilim
cached data.
3.13 Reloading of data from remote service has Kilim
been properly designed to prevent
performance issues at server-side.
(manual reloading of data can reduce the
amount of server calls)
3.14 Does the app go to sleep mode when Kilim
running in the background (prevent
battery drain)
APP USER INTERFACE CHECKS

This checklist is based on the recommendations of Apple and some other experts. This
checklist is not a substitute for a usability test, to get a good feeling of the user
experience of an app a user experience test is always the most reliable method.

# Description Responsible TE? Remarks

4.1 To keep controls as unobtrusive as possible Kilim
for instance by fading them out if they are
not used for a while.
4.1 Make it possible for users to go back to a Kilim
previous screen for instance by adding a
back or cancel button
4.2 The main function of the app should be Kilim
apparent immediately. It should speak for
itself.
4.3 Use at most one action on the screen that is Kilim
highlighted as the most likely for the
user. (Example: in iOS a blue button
represents the default or most likely
action).
4.4 Minimize user actions by using a picker or a Kilim
table view where users can select a
certain choice over a data entry field
where users have to type a choice
4.5 In an app, the user should not be able to Kilim
store files locally, outside the app
sandbox.
4.6 In an app, the user should not be exposed Kilim
to the permissions of a specific file
4.7 If there is a long list of data to scroll trough, Kilim
provide a search option above the list.
4.8 If performance is slow, indicate a progress Kilim
status icon (Loading), preferably with
specific message.
4.9 In case of live filtering of data while the Kilim
user enters his search query, verify the
performance.
4.10 The appearance of buttons that perform Sarah
standard actions are not altered in the
app (for instance: refresh, organize,
trash, Reply, back, etc.)
4.11 Do not use standard buttons for other Sarah
functions then that they are normally
used for
4.12 The app should respond to all changes in Sarah
device orientation, as per the design
4.13 Tapable elements should be about 7x7 mm Joyce
in size, using the pixel density of the
target device you can calculate the
amount of pixels (chapter documentation
contains a link to different devices
compared).
4.14 Do not redefine gestures in your app that Joyce
have a standard meaning (example:
swiping from top to bottom enables the
notification center)
4.15 Requirement to login is delayed in the app Joyce
as long as possible
4.16 If the app is stopped at an unexpected time, Madhavan
user data should be saved locally and
available at start-up.
4.17 Users should be warned of the Madhavan
consequences of deleting a document
4.18 Keyboard adjusts to expected input (for Madhavan
instance numbers/letters when
expected).
4.19 Are inactive buttons clearly distinguished Kilim
from active buttons?
TERMINOLOGY

True button = Hardware button, opposite of a touch screen button.