Checklist & Testcase for Mobile testing

I. Checklist for Mobile testing

No.	Module	Sub-Module	Test Case Description	Expected Result
1	Installation		Verify that application can be Installed Successfully.	Application should be able to install successfully.
2	Uninstallation		Verify that application can be uninstalled successfully.	User should be able to uninstall the application successfully.
3	Network Test Cases		Verify the behavior of application when there is Network problem and user is performing operations for data call.	User should get proper error message like “Network error. Please try after some time”
4			Verify that user is able to establish data call when Network is back in action.	User should be able to establish data call when Network is back in action.
5	Voice Call Handling	Call Accept	Verify that user can accept Voice call at the time when application is running and can resume back in application from the same point.	User should be able to accept Voice call at the time when application is running and can resume back in application from the same point.
6		Call Rejection	Verify that user can reject the Voice call at the time when application is running and can resume back in application from the same point.	User should be able to reject the Voice call at the time when application is running and can resume back in application from the same point.
7		Call Establish	Verify that user can establish a Voice call in case when application data call is running in background.	User should be able to establish a Voice call in case when application data call is running in background.
8	SMS Handling		Verify that user can get SMS alert when application is running.	User should be able to get SMS alert when application is running.
9			Verify that user can resume back from the same point after reading the SMS.	User should be able to resume back from the same point after reading the SMS.
10	Unmapped keys		Verify that unmapped keys are not working on any screen of application.	Unmapped keys should not work on any screen of application.
11	Application Logo		Verify that application logo with Application Name is present in application manager and user can select it.	Application logo with Application name should be present in application manager and user can select it.
12	Splash		Verify that when user selects application logo in application manager splash is displayed.	When user selects application logo in application manager splash should be displayed.
13			Note that Splash do not remain for fore than 3 seconds.	Splash should not remain for fore than 3 seconds.
14	Low Memory		Verify that application displays proper error message when device memory is low and exits gracefully from the situation.	Application should display proper error message when device memory is low and exits gracefully from the situation.
15	Clear Key		Verify that clear key should navigate the user to previous screen.	Clear key should navigate the user to previous screen.
16	End Key		Verify that End Key should navigate the user to native OEM screen.	End Key should navigate the user to native OEM screen.
17	Visual Feedback		Verify that there is visual feedback when response to any action takes more than 3 seconds.	There should be visual feedback given when response time for any action is more than 3 second.
18	Continual Keypad Entry		Verify that continual key pad entry do not cause any problem.	Continual key pad entry should not cause any problem in application.
19	Exit Application		Verify that user is able to exit from application with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.	User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.
20	Charger Effect		Verify that when application is running then inserting and removing charger do not cause any problem and proper message is displayed when charger is inserted in device.	When application is running then inserting and removing charger should not cause any problem and proper message should be displayed when charger is inserted in device.
21	Low Battery		Verify that when application is running and battery is low then proper message is displayed to the user.	When application is running and battery is low then proper message is displayed to the user telling user that battery is low.
22	Removal of Battery		Verify that removal of battery at the time of application data call is going on do not cause interruption and data call is completed after battery is inserted back in the device.	Removal of battery at the time of application data call is going on should not cause interruption and data call should be completed after battery is inserted back in the device.
23	Battery Consumption		Verify that application does not consume battery excessively.	The application should not consume battery excessively.
24	Application Start/ Restart		1. Find the application icon and select it 2. “Press a button” on the device to launch the app. 3.Observe the application launch In the timeline defined	Application must not take more than 25s to start.
25	Application Side Effects		Make sure that your application is not causing other applications of device to hamper.	Installed application should not cause other applications of device to hamper.
26	External incoming communication – infrared		Application should gracefully handle the condition when incoming communication is made via Infra Red [Send a file using Infrared (if applicable) to the device application presents the user]	When the incoming communication enters the device the application must at least respect one of the following: a) Go into pause state, after the user exits the communication, the application presents the user with a continue option or is continued automatically from the point it was suspended at b) Give a visual or audible notification The application must not crash or hung.

 

II. Testcase for Mobile testing

TEST 1 — Installation
TEST STEPS
Before starting the test round, use a file manager to note the free user space available on the phone. You will need this information in test 8.
1	Install the application being tested. The application must install without error.
2	During installation note the version number presented to the user. The version number must match that specified during submission.
3	Verify that the application has successfully installed on the device by navigating to the area on the phone where new applications are installed. The application should present one or more icon(s) on the phone.
Notes
For any submissions which do not appear obviously once installed, the submitter must include details in the submission statement of how successful installation can be verified. If the content does not appear obviously on the device once installed, and specific instructions are lacking in the submission statement, then this test will be failed.

TEST 2 – Application start/stop behaviour
TEST STEPS
1	Start the application by selecting the icon or following the steps outlined in the submission statement Navigate to the Task Manager and check that the application appears there.
2	Close the application from the Task Manager. Exit the Task Manager, and re-launch the Task Manager. The application must no longer appear in the Task Manager.
3	Start the application as in Step 1. Go to the Task Manager to verify that the application is running. The application must appear in the task manager.
4	Close the application from within the application UI and then return to the Task Manager. The application must no longer be running and must no longer appear in the task manager.
5	Restart the application as in Step 1. Navigate to the Task Manager. The application must once again appear in the Task Manager.
Notes
An application which must run in the background does not need to appear in the Task Manager or present a UI so long as the developer justifies this behaviour during submission. All applications must have some way of verifying that they are running on the device, though, and the developer should provide this information.

TEST 3 — Application credentials
TEST STEPS
1	With the application running, check the name of the application displayed on the phone. The application must display the same name on the phone as stated during submission.
2	Note the functionality of the application as it runs on the device. The basic functionality of the application must match that declared during submission.
Notes
Step 1 does not apply to applications which do not have a UI VoIP applications must present a UI in order to pass this test.

TEST 4 — No disruption to voice calls
TEST STEPS
1	With the application installed and running use a second phone to call the test device. The incoming call must be indicated to the user on the test device.
2	Answer the call on the test device. You must be able to conduct a conversation with the other party without interference from the application being tested.
3	End the call in the normal way on the test device. The voice call must be ended.
4	From the test device, make a call to a second phone. Answer the call from the other device. The call must be indicated on both devices, and you must be able to conduct a conversation with the other party without interference from the application being tested.
5	End the voice call from the second device. The call must be ended on both devices.
6	Place a test call to the emergency 112 number from the device. *Please check in your territory for the approved way to make test calls to the emergency services.
Notes
If the application being tested has the MultimediaDD capability, and has audio functionality, then that functionality must be in use whilst this test is performed. Particularly, it should be checked that the audio from the application is faded down to allow the user to hear the telephone call. VoIP applications will need this test running using both the handset held to the user’s ear and using a headset. The test should be run with a VoIP call in progress, and the incoming GSM call should be announced with call waiting tones.

TEST 5 — No disruption to text messages
TEST STEPS
1	With the application installed and running, send a text message to the test device. The incoming text message must be notified to the user as per their alert settings.
2	Read the text message on the test device and choose to reply. Send the reply. The reply must be received at the second device.
3	From the standby screen on the test device, navigate to the “new text message” option and create a new message. Send the message to the second device. The message must be received at the second device.

TEST 6 — Auto-start behaviour
TEST STEPS
1	With the application running, find the settings for the application — either within the application itself or from the settings option on the device. There must be an option which allows the user to enable/disable auto-start functionality.
2	Ensure that the setting for auto-start behaviour is disabled, and restart the device. The application must not start on device boot.
3	Now change the setting so that auto-start behaviour is enabled for the application and restart the phone. The application must start when the phone boots.
Notes
If the application does not have auto-start functionality, then this test does not need to be run.

TEST 7- No disruption to key device applications
TEST STEPS
1	Ensure that the contacts, messaging and calendar applications are populated with data and start the application as in Test 2. After the application has been installed and used, the data entered into those applications must not be altered in any way without the user being aware.
2	With the application running, navigate to the messages application and create a new message. Save that message to the drafts folder and then open and edit it. Finally, delete the message from the drafts folder and delete a message from the inbox. All of the above actions should be possible without interference from the installed application.
3	Navigate to the contacts application. Create a contact, then edit that contact and then delete it. The application should not interfere with any of the actions above without notifying the user and giving them option to avoid the change.
4	Navigate to the calendar application. Create an appointment in the calendar. Edit the appointment and then delete it. The application should not interfere with any of the actions above without notifying the user and giving them option to avoid the change.
5	Use the web browser on the device to go to a web page which is known to work on the network being used. It must be possible to create a data connection and to access the web page selected.
Notes
If the application, as part of stated functionality, makes changes to user data then an exception can be claimed here. The functionality must be described in the documentation with the application and all data other than that mentioned in the user guide must remain untouched as described in the test case. The data used in this test case is also needed for Test 8, so leave the data on the device when proceeding straight into Test 8.

TEST 8 — Un-install
TEST STEPS
1	Stop the application as described in Test 2 and uninstall the application using the system installer. The application must be uninstalled without error.
2	Following the same steps as in Test 1, navigate to where you would expect to see the application icon. The application icon must not longer be present on the device. If you used another method to verify successful installation in Test 1 then use this method to ensure that the application has been uninstalled.
3	Check the contacts, messages and calendar applications to ensure that that the data present in Test 7 is still present in those applications.
4	Using the same file manager as at the start of Test 1 check that the amount of user space available on the device is either the same as that found in step 1 or that any difference between the space available before and after fulfils the following criteria. a) Excluding user-generated and downloaded content, the application leaves no more than 100Kb of data on the phone after uninstall b) Any data left on the device after install matches the explanation given during the submission process
Notes
You should start this test with the application data from Test 7 still in place on the device.

TEST 9 — Device adaptation
TEST STEPS
Note: The following test steps should be run on the list of devices corresponding to the UIDs specified in the .pkg file. The lead device list can be found at http://tiny.symbian.org/devicetable
1	Install the application onto the device The application should install on the device or present an error message to explain that it cannot install onto that device.
2	Launch the application. The application should run on the device or present an error message to explain that it cannot run on that device.
3	Briefly examine the application whilst running. UI elements should be functional and text should be readable in the main screen of the application.
4	If the device on which the application is currently being tested supports portrait and landscape screen modes, start the application and then switch between the screen modes. The application should continue to be functional, and usable, in both screen orientations of the device, whether or not the application rotates in response to the screen mode change.
5	Close the application from the application UI The application should stop running.
6	Uninstall the application from the phone. The un-installation should happen without error and the application must be un-installed.
Notes
Applications which do not present a UI to the user in normal usage do not need to run this test. On the primary device — on which all of the other test cases have been run – only step 4 of this test should be performed as all of the other steps of this test case are covered elsewhere.

Additional Tests for VoIP applications

Note that Test 3 and Test 4 both contain additional notes which apply to the testing of VoIP applications. Please read and apply these notes when running those tests on VoIP applications.

Test 10 — Additional emergency call testing for VoIP apps
TEST STEPS
Note: These test steps should be performed twice — once with a SIM card in the device and once without.
1	With the VoIP application running in the background, but with no VoIP call in progress, initiate an emergency call in the usual way. The emergency call must be placed over the GSM/CDMA network successfully.
2	With the VoIP application running in the background with a VoIP call in progress, initiate an emergency call in the usual way. The emergency call must be placed over the GSM/CDMA network successfully and the VoIP call should be terminated or placed on hold.
3	With the VoIP application in the background, and an emergency call active make a VoIP call to the device. The incoming VoIP must be rejected, and the emergency call must not be interrupted.