MOBILE APP TESTING CHECKLIST V

Store specific checks

The app cannot download code to be installed without the users consent.

The app can only get new functionality by way of an upgrade through the app store.

After download, an app should remain working. An app cannot turn off after a few days.

An app can’t be a “trail”, “beta”, “demo” or “test” version.

Apple product names should be spelled correctly in the app. (For instance: IPhonez is wrong).

If the app uses the web, it is not done using third party (i.e. non-Apple) browsers.

You cannot mention other app platforms in your app (for instance: “Also available on android!”)

An app cannot use old interfaces, like for instance the iPod click wheel.

Functionality should be in sync with functionality described in store.

The app can’t use the user’s location without permission.

All url’s in the app code should be fully functional

The location services cannot be used to autonomously control of vehicles or for emergency services.

An app cannot use push notifications without user consent.

Push notification can’t send personal information.

The App may not distribute any private information of users (like Player ID) through the game center.

Ad banners must be hidden when there are no ads available.

The app must respect copyright of apple and other parties.

An app can’t restrict the users of the app for instance by location or carrier.

The in app purchase mechanism cannot be used to purchase goods and services used outside the app.

The in app purchase mechanism cannot be used to collect money for charities. This has to be done through SMS.

The in app purchase mechanism cannot be used to buy a raffle or lottery ticket directly from the app.

Apps that encourage the users to use the device in a way that may damage the device will be rejected

An app cannot require user’s personal information (for instance email address) in order for it to function.

An app cannot use location services of the device without asking permission.

An app cannot send spam or introduce viruses, or use other apple platforms like Game Center and Push Notifications to do so.

Push notifications have to be send using the Apple Push Notification (APN) API. This has to be done using an APN ID.

Multitasking functionality of the app can only be used for its intended purposes, i.e. VoIP, Audio playback, location, task completion, local notifications, etc. This means that generally an app can’t run in the background but has to be closed off if it’s not used any more.

The app must have some functionality. For instance, it can’t be just a title page leading to some text. It can’t be just a song, movie or book as there are different platforms for that.

The app can’t use any “non-public API’s”. This means that you can’t use some functions that the distributing platform uses for its own apps. (This can generally be checked best by some sort of automated tool, like http://www.chimpstudios.com/appscanner/)

The app can’t reprogram controls of the device that are not intended for that use. (For instance: using the volume button as a shutter for the camera).

The app should aim at backing up a minimum of information on iCloud. The information in iCloud should be just the user generated information. Information that can be recreated or downloaded should not be backed up.

The app should not access information on the device outside the app without the user’s permission (for instance, copying the address book or getting information from other apps).

The app should not access or write files outside the “Bundle” and “Documents” directory. (because the app can’t read or write data outside the designated container area).

In general, the app has to be decent. So no explicit material in the sense of sex, violence, drugs, alcohol or tobacco. It cannot address a specific ethnic or religious group in a derogatory way.

The app has to be honest. This means that the description of the app has to be correct, and all functionality has to work as described. If an app gives diagnostic information, it has to be reliable. This also means that the genre and category in the  description must be appropriate. The app icons should be consistent and appropriate.

Testing GUI

To test any Windows based application following points are to be considered:

- It is essential to have GUI consistency within the Application.

- Should be alike in look and feel as per any other standard Window software.

- Should have standard set of keys implemented for the software.

- Should have clean and neat exit.

While testing any Windows based application the testing can be broadly categorized into following compartments. They are:

- Standardization Testing.

- GUI Testing.

- Validation Testing.

- Functionality Testing.

Standardization Testing

This compartment mainly emphasizes on the standardization part of the application. Standardization means that the application being developed should have standard look and feel like any other window application. The general guidelines are as follows:

1. The application should have first "About Application" screen displayed.

2. Most of the screens/ dialog box (as on context) should have Minimize, Restore and Close clicks.

3. Proper icon should be attributed to the application

4. All screens/ dialog box should have a proper caption as per the context used.

5. The application should be seen in the Windows Task Bar as well as status bar.

GUI Testing

This compartment mainly emphasizes on the GUI - Graphics User Interface aspect of the Application. It is not concrete that once GUI guidelines are set that can be followed blindly. GUI standards may vary from company to company and also from application to application. But still one can set general guidelines to have an overall idea on how to start GUI testing. These guidelines apply for every screen/ dialog box of the application. General guidelines are:

1. All the dialog box should have a consistent look through out the Application system. For e.g.- If the heading within a dialog box is blue then for each dialog box the heading should be of this color.

2. Every field on the screen should have an associated Label.

3. Every screen should have an equivalent OK and cancel button.

4. The color combination used should be appealing.

5. Every field in the dialog box should have a Short Cut Key support. For e.g.- User Name

6. Tab order should be normally set horizontally for the fields. In some case as per the case the Tab Order can be set vertically.

7. Mandatory fields should have * (RED ASTERIK) marked to indicate that they are mandatory fields.

8. Default key <Enter> should be set as OK for the dialog box.

9. Default key <Esc> should be set as Cancel for the dialog box.

Validation Testing

This compartment mainly emphasizes on the Validation aspect of the Application. Validation testing mainly depends on the fields set in the dialog box and the functions it has to perform. But still there are certain common rules that can be applied. General guidelines are:

1. For text box fields where value entered has to be numeric check following:

¨ It should accept numbers only and not alphabets.

¨ If field usage is such that for e.g., To accept

Total number of days

Telephone number

Zip code etc.

then it should not accept 0 and negative values.

2. For text box fields where value entered has to be alpha-numeric check following:

¨ It should accept alphabets and numbers only.

¨ If field usage is such that for e.g., accepting

First Name

Middle Name

Last Name

City

Country etc.

then field value should start with an alphabet only.

¨ Depending on the condition this fields may accept special characters like -, _, . etc.

3. If the field is a combo box then it has to be checked for following points:

¨ Check the combo box has drop down values in it, it is not empty.

¨ Drop down values should be alphabetically sorted. This might change as per requirement but as standard practices it should be alphabetically sorted. For e.g. to select data type from the list it will be as follows:

Date

Integer

String

Text, etc.

¨ Selection of any drop down value is displayed on closing and opening the same dialog box.

¨ By default some value like "Select Value" or "_______" string is displayed. This is because User comes to know that value is to be selected for this field. Avoid displaying the first default value in the list.

4. If the field is a list box then it has to be checked for following points:

¨ Check the list box has values in it, it is not empty.

¨ List box values should be alphabetically sorted and displayed. This might change as per requirement but as standard practices it should be alphabetically sorted.

¨ Selection of any list box value should put a check before the value and should display the correct value(s) selected on closing and opening of the same dialog box.

¨ If the list box supports multiple selection then check whether multiple values can be selected.

5. If the field is a list of radio button then it has to be checked for following points:

¨ Check whether as per requirements all the values are listed. For e.g. to select date format. Possible values displayed will be as follows:

mm/dd/yyyy

dd/mm/yyyy

mm/dd/yy

dd/mm/yy

yyyy/mm/dd etc.

¨ Same selected value should be displayed on closing and opening of the same dialog box.

6. Data Controls are to be tested as part of functionality testing.

Functionality Testing

This compartment mainly emphasizes on the Functionality aspect of the Application. The first step to test the Functionality aspect of the Application is to check whether all the requirements are covered in the software. The actual functionality testing totally depends from software to software. Still one can frame general guidelines. General guidelines are:

1. Check the functionality is covered as per Requirement specifications or Functional specifications developed for the software.

2. Within a dialog box identify the dependent fields. Depending on the dependency check the enabling and disabling of the fields. For e.g.: to create Contact addresses in any application. To create contact addresses user should be able to add, delete and modify the information. Contact Addresses will contain information like, First Name, Last Name, Address1, Address2, City, State, Country, Zip, Phone, etc., any other information may also be added.

This form will have the required fields and in addition to that will have Add, Delete and Update buttons. The functionality of the buttons is as follows:

¨ Initially only Add button will be enabled. Delete, Update buttons will be disabled. This is because initially there is no data available and unless one adds one cannot delete or update. In short, unless there is a single valid record available it is not possible to update or delete.

¨ Only on selecting a record from the list Delete and Update buttons are enabled and Add button is disabled. By default No records will be selected.

¨ Delete and Update should always give confirmation message before actually performing the operation.

¨ Delete operation should not show the deleted item in the list.