Testing Checklist for Mobile Applications

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.

Mobile Application Testing

Contents
1 10- Things You Need to Know About Mobile Apps 2
2 Reasons Why Mobile Apps Need Testing 4
3 Mobile Application Testing Challenges 6
4 5-Things to keep in mind before starting Mobile Application Testing 8
5 Symbian Signed Tests Cases v 4.0.14 9
6 Testing Checklist for Mobile Applications 18
7 Test Plan for a mobile applications 22
8 How to setup Android SDK on Linux ubuntu 28

References
Anurag Khode – Quality Analyst at Umundo Inc
Ed Thomas
Manish Phegade(Technical Associate) & Sangram Desai (Sr. Technical Associate)
Source-WIKI Forum Nokia
Source:-http://www.qcubicle.com/mobile-testing/mobile-application-testing-challenges/
1 10- Things You Need to Know About Mobile Apps
The Internet Advertising Bureau (IAB) has put together a list of 10 things everyone should know about mobile applications, or at least, it’s got 10 of its members to think of one each. We’re happy to share their advice with you…
1. Only do apps when you need more
Compared to browsing, mobile apps offer a richer level of user interaction, allowing more complex graphics, media and information to be presented. They also provide a more robust and secure environment for user engagement. But, if you can deliver what you are trying to achieve through a browser, you will be able to reach far more consumers. Jeremy Copp, CEO, Rapid Mobile Media Ltd
2. Tell people about your app
Don’t just rely on app stores; you can distribute apps via mobile sites, operators and through multiple ad placements and formats for maximum impact and reach. Theo Theodorou, EMEA Sales Manager, Mobile Advertising, Microsoft Advertising
3. Think further than the iPhone
The iPhone offers fantastic functionality for developers and users alike, and apps developed for the platform are eminently PR-able, and are often shared virally. It has a fast growing user base, and reaches relatively wealthy 25-44 year olds, who actively use mobile media very well. But also developing a java version, optimised to work over a wide range of handsets, including BlackBerrys, will give you a far greater potential reach.
Mark Angell, Business Development Director, Marvellous
4. Get the balance right
There are two fundamental balances to achieve.
Firstly, business objectives versus user needs: for the application to be effective, the business needs must carefully consider the user, as well as commercial objectives. Secondly, the three E’s (Engagement, Entertainment and Effectiveness): functional apps often outlast the usage of entertainment-based apps.
Paul Taylor, Strategist & Planner, COI
5. Consider the average app user
There are 8.7 million people who have used a downloaded app in the UK, which is 18% of mobile users. 60% of these users are playing games that they have downloaded. The median age of an app user is 32 years old, and 43% are female. 36% of app users own Smartphones, compared to 15% of the total market.
Alistair Hill, Analyst and Mobile Products, Europe, comScore
6. Brand-building versus sales
Free applications get the most downloads, whereas paid-for applications generate revenue. Knowing whether you are branding or selling is a key point when launching your first application.
Ross Butler, Creative, Parrott and Miller
7. Product longevity is essential
Every service needs a roadmap, no matter how basic. Customers will quickly get bored with a uni-functional app which has no new features or capability added over time. By adding functionality as time goes on, you can create brand advocacy.
Christian Harris, CEO, Gorillabox
8. Send them in the right direction
Ads in existing applications are a great place to advertise, but make sure that the destination site is optimised for mobile. If it isn’t, then you risk low conversion and a poor perception of your brand.
Jonathan Abraham, Brand Sales Director, AdMob
9. Test, test and test again
If a customer can access it on their handset it needs to work. If it doesn’t, it will do more damage than good to your brand. Invite feedback, and always read customer reviews, to ensure you are meeting the needs of your consumer.
Oliver Newton, Head of Emerging Platforms, i-level
10. Be on brand
Just as with any form of communication, ensure that your app is ‘on brand’. Tone of voice, brand values, message, production values and brand fit are essential in making a great brand application.

2 Reasons Why Mobile Apps Need Testing
Guest Post By- Ed Thomas
For any mobile app developer hoping to produce a top quality mobile application, app testing is an essential part of the app development process. Here are several reasons for getting your application tested by a mobile app testing professional before its consumer release:
1. Check the Basic User Experience
After designing and developing a mobile app you will need it to be tested by a group of eager mobile users. This simply requires the application to be test run in it’s simplest form – fully using the app for it’s intended purpose. Users at this testing stage should be asked to give feedback on the complete user experience and record any glitches they discover. Screenshots can be extremely useful at this point, and if the app in question is iPhone based there is no excuse for making the most of the screen capture function.
2. Test Navigation
Whilst basic user testing may bring awareness to navigation problems, computer based app testing is the most accurate way of checking full app navigation. This process will check all menu functions are correctly working and that both internal and external links are accurate.
3. Test System and Negative Usage
By performing app tests, a developer can accurately determine how your application will function in various conditions. Testing the apps reactions to system changes such as low memory or low battery as well as putting the application up against negative challenges such as malicious attacks.
4. Check for Hidden Defects
If all is well with the general user experience of your app, there could still be hidden issues that could cause sporadic performance or later problems. These defects are found through both software and hardware tests and are only completely detectable through professional services.
5. Check Connectivity
Many iPhone apps rely on internet connectivity in some form or another after original download (even if just for updates). Monitoring how a mobile app functions in conditions of low internet connectivity or mobile signal is a very important stage in mobile app testing and will ensure that any problems formed during app development can be corrected before release.
6. Test Audio Functionality
Another area which needs to be tested is the apps ability to interact with various audio settings on different handsets. App details including audio and vibrate feedback (when a sound or buzz plays on a touch) also need to be thoroughly checked to eliminate any future glitches.
Author: Ed Thomas has a wide expertise in the field of apps development and website development. He is one of the reputed app developers UK and shares his expertize through his scholarly articles.

3 Mobile Application Testing Challenges
Source:-http://www.qcubicle.com/mobile-testing/mobile-application-testing-challenges/
Principal objective behind mobile application testing is to ensure best user experience, when access from mobile devices. Mobile web application testing first will be done on web browser using various mobile device user agents. Later will start testing application using emulators or simulators. Most the web sites are designed for delivering content for desktop application, Notebook or for wide range of handheld devices. The best practices of delivering Web content to mobile devices is process and deliver content by which user agent or devices. Web content should be delivered according to the mobile devices.
Factors affect mobile content delivery
1) Types of content
2) Network, Carrier, User type and device capabilities
3) Context in which the content is received
4) User Goals
Mobile users typically have different interests to users of fixed or desktop devices. They are likely to have more immediate and goal-directed intentions than desktop Web users. Their intentions are often to find out specific pieces of information that are relevant to their context.
Content delivery bothers both mobile user and carrier as well. E.g. when page size is large, device will not be able to handle it. Page should be cropped or resized and delivered without losing relevant information. Also page can divide into fragments and display in multiple pages. Scrolling to read documents or web page will not be user friendly
Another example is image handling capabilities
Page UI will be broken or timeout error message displayed on screen, when content delivers with a bigger image size. Image should be cropped or resized before it delivers to mobile device. Image delivery should be in size range which device can handle without any burden.
More areas to consider while mobile Application testing
• Bandwidth – Carrier or device should be GPRS, Edge, 3G or 4G compatible
• Mobile handset Capabilities like screen size, memory size etc.;
• Cost -Cellular network connectivity is commonly charged per data volume. Data transfer should be minimum while accessing pages.
• Input -Mobile device input capabilities like keyboard, touch screen etc
• Text input -Text input tends to be very slow and cumbersome on a mobile device
• Device screen flip capabilities- Page layout or content will change when user access page in different screen modes
• Pop ups or redirection – Pop ups or redirection while doing testing is very annoying for users.
Mobile application Testing
Carry out testing on actual devices as well as emulators. Many manufacturers provide emulators for their device that can provide a convenient preliminary means of testing. However, in practice, many of these emulators behave in a different way to actual devices they emulate. Consequently testing should be carried out in as wide a range of real devices and specific software versions as is practical. When your application is not carrier specific then testing become more challenging Carriers provide mobile handsets with customized preloaded applications or browser versions .This may internally again effect application performance and testing. Testing or Using an application on a device, which does not have Back button is even more interesting (will required a small R&D to find how user can navigate back).Entering long URL in mobile browser address bar for Module testing. Few emulators does not support copy paste URL .But luckily in Device Anywhere studio copy paste is possible. This saves lot time in entering an URL in device browser.

4 5-Things to keep in mind before starting Mobile Application Testing
Before starting testing any mobile applications (let it be .chatting tools, social networking, games, business apps) there are some things that a Mobile Application Tester should go through for effective testing.
1. Analyzing similar applications:- Try to analyze some other application which are similar to your application. For example if you have to test any media sharing application on Mobile just search for some other media sharing applications and observe its feature.
2. Keep your emulator ready for testing : Some times it takes times for processing any request for example for downloading any media files or for loading an page on device. In this case to save time you may try some test with your emulator so that this time will be utilized and overall time in testing will be reduced.
3. Analyze the device related issues:- When it is deviced which are the target devices do not forget to have a look on device related known issues. This will help you understand which are the issues related to device and which are due to your application under test.
4. Use emulator but don’t completely trust it:- While testing you may take help of emulator but please note that all the test cannot be performed in emulator. Also in emulator response time is faster, so it may happen you may miss some issue which comes in weak network on actual devices.
5. Define the performance criteria:-For any mobile applications performance is one of the most important concern. Make sure you are having some performance parameters so that you will be testing the mobile applications against it. Since Memory is one of the constraints for mobile devices performance and behavior of your application under these conditions is interesting things to see.

5 Symbian Signed Tests Cases v 4.0.14
This version of the test criteria is in effect from 5th January 2010.
Reference: Symbian Signed Test Criteria
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.

6 Testing Checklist for Mobile Applications

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.

7 Test Plan for a mobile applications
Source-WIKI Forum Nokia
1 Introduction
1.1 Overview
This document explains the testing methodology for a mobile application, and is to be used as a guide for the testing activity.
The intended audience for this document: The Project Managers Product development team members Test engineers
1.2 Scope
The scope of testing as explained in the document is to test the operating characteristics of an application that runs on mobile devices supporting J2ME. The tests are organized by requirement category such as usability, functionality, security, etc. The procedure for carrying out testing in terms of preparation of test cases, test environment setup, defects logging and reporting are explained.
The article does not address the following:
• Content censorship (i.e. assessment against standards for violence, gambling, political messaging etc.) for the purpose of preventing the deployment or sale of an application. Distribution, DRM etc.
• Testing requirements specific to a particular manufacturer’s (or network operator’s) device, user interface, and standards (e.g. WAP) implementation.
1.3 References Mention the documents of references
1.4 Acronyms
Acronym Expansion
DRM Digital Rights Management
J2ME™ Java™ 2 Platform Micro Edition
2 Test Plan and Strategy
2.1 Unit Testing
2.1.1 Objective
The objective of Unit testing is to verify that a particular module of source code is working properly. Unit tests are designed to test a single class or component or module in isolation. Developers run unit tests, and only for the components they are working on.
2.1.2 Entry Criteria
• Test cases are reviewed
• Build is complete and self test done
• Unit Test environment is set up
2.1.3 Exit Criteria
• All planned test cases are executed
• Units are working as per the expected results
• Defect are fixed in the code and tracked to closure
2.1.4 Logging Tests and Reporting
The developer will fix the defects that are found in unit testing. Additionally, if defects corresponding to other modules or components are found during unit testing, these will be reported.
2.2 System Testing
In System Testing, separate units (packages / modules / components), or groups of units of the application are united and tested as a completely merged application. The purpose of System Testing is to identify defects that will only surface when a complete system is assembled. Verification of the system at this stage might include: functionality, usability, security, installation etc. It is intended to validate the application as a whole.
The rest of this document mainly explains how System Testing is performed by the testing team.
2.2.1 Testing Procedure
The steps in testing consist of:
• Creation of all the test scenarios and test cases
• Preparation of a test case document that has a brief description of the test case , steps to conduct tests and expected result
• Defect Report generation.
Outlined below are the main test types that will be performed
a. Application Characteristics (AC) – Information about the application is provided to help the testing team in the testing work.
b. Stability (ST) – Focusing on the application being stable on the device.
c. Application Launch (AL) – Once an application is loaded it must start (launch) and stop correctly in relation to the device and other applications on the device.
d. User Interface (UI)
e. Functionality (FN) – Documented features are implemented in the application and work as expected. Sources for the information are user manuals, formatted application specification documents and online documentation.
f. Connectivity (CO) – the application must demonstrate its ability to communicate over a network correctly. It must be capable of dealing with both network problems and server-side problems.
g. Personal Information Management (PI) – The application accessing user information needs to be able to do it in an appropriate manner and not to destroy the information.
h. Security
2.3 Regression Testing
This is an additional step, and is done prior to taking up system testing which is to test new functionality. Regression testing consists of running a set of standard tests to ensure that old functionality has not been broken by new functionality. Regression tests are also run if a new release is made after fixing a number of defects.
2.4 Pass/Fail Conditions
It is expected that an application must pass all the tests in each test category to be successful.
2.5 Test Report
For each report, the following information is provided: • The name of the application
• The version number of the application
• Device used for testing
• Device firmware version
For each error reported, the following information is provided: • Description of the error
• Frequency of occurrence of error: Systematic or Random or Once
• Location of the error in the application
• Steps to reproduce the error
3 Schedules for Testing
This will be decided in consultation with the project manager.
4 Risks and Assumptions
4.1 Risks:
The following may impact the test cycle:
• Device availability
• Any new feature addition/modification to the application which is not communicated in advance.
• Any delay in the software delivery schedule including defect fixes. Any changes in the functional requirements since the requirements were signed-off/formulated
4.2 Assumptions:
• Every release to QA will accompany a release note specifying details of the features implemented and its impact on the module under test.
• All “Show-Stopper” bugs receive immediate attention from the development team.
• All bugs found in a version of the software will be fixed and unit tested by the development team before the next version is released
• All documentation will be up-to-date and delivered to the system test team.
• Devices, Emulators and other support tools will be fully functional prior to project commencement.
• In case of lack of required equipment or changes in the feature requirements, the test schedules may need to be reviewed.
5 Entry and Exit Criteria
5.1 Entry Criteria
• Development of the application is complete
• Successful completion of unit testing for the applications
• Release of software to the test environment
• Dedicated resources are allocated
• Approved test bed to carry out system testing.
• Test environment is up and working
5.2 Exit Criteria
The Following is the criteria when the testing will be stopped for this module:
• All test cases have been executed and at least 95% have passed successfully. The remaining 5% do not impact critical functionality
• All test results have been evaluated and accepted.
• There are no showstoppers or high criticality defects unresolved or outstanding
6 .Test Metrics
Following metrics will be captured and reported as part of the Test
• Summary Report
• Test Design effort
• Test execution effort
• Number of Test Cases executed
• Number of Defects and their classification
• Test Coverage (Number of test cases executed/Number planned)
7 Logging Tests and Reporting
Some third party applications will be used for reporting bugs found during test execution. The QA team will log defects in the tool as testing progresses.
8 Roles and Responsibilities
The roles and responsibilities of the testing team for the project are as follows:
8.1 Project Manager / Test Manager Responsibilities:
• Overall responsibility for managing the testing process
• Approval of test documents
• Approval of inspections/reviews done as per the test plan
• Providing resources for the project
8.2 Test Lead
Responsibilities:
• Requirement gathering
• Planning and estimating for testing
• Tracking and monitoring the testing as per the test plan
• Reporting the project status
8.3 Test Engineer
Responsibilities:
• Creating the test cases as per the test plan
• Executing the test cases
• Documenting the results and logging errors.
9. Deliverables
• Test Plan
• Test Cases Document – Document with a description and expected result for each test case.
• Test Results – The Pass/Fail status of each test cases and the list of issues.

8 How to setup Android SDK on Linux ubuntu
How to setup Android SDK on Linux ubuntu(Ubuntu 10.10 in our case)
Guest Post By:- Manish Phegade(Technical Associate) & Sangram Desai (Sr. Technical Associate)
Friends, You know very well that Android is the buzzword nowadays and it is just rocking all the way in mobile arena. Being open source and as the learning curve is pretty easy we cannot stop ourselves being avid admirer of Android. Everything is just going great with Android for now. As a developer or tester you must have installed Android SDK on windows OS and it must be pretty easy for you going along with it. But have you ever wondered how can we develop the android apps in Linux OR one step behind How to install Android SDK on Linux?
Well, there was a requirement in our project where we have been asked to develop the project in Linux than our traditional platform Windows. We literally had to start from scratch and we faced quite a lot problems while installing Android SDK on Linux since both of us were newbie in Linux. So here in this article we are going to tell you something interesting. We are going to explain the step by step process of how to install Android on your Linux machine. I hope you will like it as it is pretty interesting. So let’s get started.
The main components required are:
• Android SDK setup, Eclipse ( A development environment for java and now android)
• ADT plugin for eclipse
• JDK(Java Development Kit)&
• JRE(Java runtime Environment).
Please note that you may not need to install eclipse & ADT plug in if you are just going to use the setup for testing.
I hope you have a basic idea about Linux command line &.bash. If not just have a look atthem before starting.
Step by Step Guide to Install Android SDK on Linux:-
1) Download JDK and JRE:
➢ download Jdk1.6 and jre1.6:
Download following installation files from Sun java site.
✔ jdk-6u23-linux-i586.bin
✔ jre-6u23-linux-i586.bin
➢ Install JRE and JDK
➢ Set JAVA_HOME / PATH variables Under Linux Bash Profile:
In linux, unlike windows all the environment variables and the corresponding paths are saved in a special file known as .bashrc file. This file is hidden. It is stored in your root folder. So after going into root folder, click on “View option-> show hidden files”.
The.bashrc file will now be visible. Open this file and add following lines at the bottom:-
e.g. If your path is set to /usr/java/jdk1.5.0_07/bin/java, set it as follows:
export JAVA_HOME=/usr/java/jdk1.5.0_07/bin/java
export PATH=$PATH:/usr/java/jdk1.5.0_07/bin
——————————————————————————————————
2) Download and install Android SDK for linux:
URL: – http://dl.google.com/android/android-sdk_r08-linux_86.tgz
After downloading, unzip the file and save it at appropriate location and also set the
path at very bottom of .bashrc file as:
export PATH=${PATH}:/home/”Your loginfolder”/android-sdk_r08-
linux_86/android-sdk-linux_86/platform-tools
——————————————————————————————————
3) Download ADT 8.0.1.
URL: – http://dl.google.com/android/ADT-8.0.1.zip
——————————————————————————————————
4) Download Eclipse 3.6 (Helios)
Eclips 3.6 can be downloaded from eclips site (http://www.eclipse.org/downloads/?tab=developer)
I have installed Eclipse 3.6 on my PC but in forums they have suggested to use
Eclipse 3.5 rather than 3.6.So here is the download link for Eclipse 3.5:-
http://archive.eclipse.org/technology/epp/downloads/release/galileo/R/eclipse-
java-galileo-linux-gtk.tar.gz
——————————————————————————————————
5) Configure Eclipse:
• Now set the path of jdk in the eclipse.
• Edit Eclipse.ini file.
• Add lines given below just above “-vmargs”.
-vm
/home/”Your loginfolder”/Downloads/New/new1/jdk1.6.0_23/bin/java
——————————————————————————————————
6) Installing the ADT Plugin in Eclipse
• Start Eclipse, then select Help > Install New Software.
• Click Add in the top-right corner.
• In the Add Site dialog, click Archive.
• Browse and select the downloaded zip file.
• Enter a name for the local update site (e.g., “Android Plugin”) in the “Name” field.
• Click OK.
• In the Available Software dialog, select the checkbox next to Developer Tools and click Next.
• In the next window, you’ll see a list of the tools to be downloaded. Click Next.
• Read and accept the license agreements, then click Finish.
• When the installation completes, restart Eclipse.
——————————————————————————————————
7) Now we have only installed the Android setup. We Now launch SDK manager and
Download the current version of android for which we need to build/test the Application.
Set Sdk path in Eclipse: – If you have installed eclipse, you need to set up the path
Of android SDK in the eclipse. Do it as follows.
• Select Window > Preferences… to open the Preferences panel (Mac OS X Eclipse > Preferences).
• Select Android from the left panel.
• For the SDK Location in the main panel, click Browse… and locate your downloaded SDK directory.
• Click Apply, then OK.
——————————————————————————————————
8 ) Go to android SDK>tools>emulator
The Emulator WILL NOT start. This is because you need to change the file
Permission as executable to let the OS know that it is an executable. Otherwise it
Won’t recognize. So:-
• Go to the android installation directory->tools->Emulator.
• Right click on emulator icon.
That’s it! You are now ready to play with the Android on Linux. Let us know if you have any query.

Follow

Get every new post delivered to your Inbox.