Contents 10- Things You Need to Know About Mobile Apps.............2 Reasons Why Mobile Apps Need Testing..........................

4 Mobile Application Testing Challenges.............................6 5-Things to keep in mind before starting Mobile Application Testing.........................................................8 Symbian Signed Tests Cases v 4.0.14...............................9 Testing Checklist for Mobile Applications.......................18 Test Plan for a mobile applications................................23 How to setup Android SDK on Linux ubuntu...................29

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/

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, its got 10 of its members to think of one each. Were 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 Dont 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 Es (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 isnt, 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 doesnt, 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.

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 its simplest form fully using the app for its 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.

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.

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 dont 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.

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. Install the application being tested. The application must install without error. During installation note the version number presented to the user. The version number must match that specified during submission. 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. Close the application from the Task Manager. 2 Exit the Task Manager, and re-launch the Task Manager. The application must no longer appear in the Task Manager. Start the application as in Step 1. 3 Go to the Task Manager to verify that the application is running. The application must appear in the task manager. 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. Restart the application as in Step 1. 5 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 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.

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 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. Answer the call on the test device. 2 You must be able to conduct a conversation with the other party without interference from the application being tested. End the call in the normal way on the test device. The voice call must be ended. From the test device, make a call to a second phone. Answer the call from the other device. 4 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. End the voice call from the second device. The call must be ended on both devices. Place a test call to the emergency 112 number from the device. 6 *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 users 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 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. Read the text message on the test device and choose to reply. Send the reply. The reply must be received at the second device. 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 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. Ensure that the setting for auto-start behaviour is disabled, and restart the device. The application must not start on device boot.

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 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. With the application running, navigate to the messages application and create a new message. 2 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. Navigate to the contacts application. 3 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. 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 Stop the application as described in Test 2 and uninstall the application using the system installer. The application must be uninstalled without error. Following the same steps as in Test 1, navigate to where you would expect to see the application icon. 2 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 4 Check the contacts, messages and calendar applications to ensure that that the data present in Test 7 is still present in those applications. 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 Install the application onto the device 1 The application should install on the device or present an error message to explain that it cannot install onto that device. Launch the application. 2 The application should run on the device or present an error message to explain that it cannot run on that device. Briefly examine the application whilst running. 3 UI elements should be functional and text should be readable in the main screen of the application. 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.

Close the application from the application UI The application should stop running. 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. 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. 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. 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.

Testing Checklist for Mobile Applications

No. Module 1 Installation SubTest Case Description Module Verify that application can be Installed Successfully. Verify that application can be uninstalled successfully. Expected Result Application should be able to install successfully.

Uninstallation

User should be able to uninstall the application successfully.

Network Test Cases

Verify the behavior of User should get proper error application when message like Network error. there is Network Please try after some time problem and user is performing operations for data call. Verify that user is User should be able to able to establish data establish data call when call when Network is Network is back in action. back in action.

Voice Call Handling

Call Verify that user can Accept 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.

Call Verify that user can Rejectio reject the Voice call n at the time when application is running and can resume back in application from the same point. Call Verify that user can Establis establish a Voice call h in case when application data call is running in background. SMS Handling Verify that user can get SMS alert when application is running.

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. User should be able to establish a Voice call in case when application data call is running in background.

User should be able to get SMS alert when application is running.

Verify that user can User should be able to resume back from resume back from the same the same point after point after reading the SMS. reading the SMS. Verify that unmapped Unmapped keys should not keys are not working work on any screen of on any screen of application. application. Verify that Application logo with application logo with Application name should be Application Name is present in application present in application manager and user can select manager and user it. can select it.

10 Unmapped keys

11 Application Logo

12 Splash

Verify that when user selects application logo in application manager splash is displayed. Note that Splash do not remain for fore than 3 seconds.

When user selects application logo in application manager splash should be displayed. Splash should not remain for fore than 3 seconds.

13

14 Low Memory

Verify that Application should display application displays proper error message when proper error message device memory is low and when device memory exits gracefully from the is low and exits situation. gracefully from the situation. Verify that clear key Clear key should navigate should navigate the the user to previous screen. user to previous screen. Verify that End Key should navigate the user to native OEM screen. End Key should navigate the user to native OEM screen.

15 Clear Key

16 End Key

17 Visual Feedback

Verify that there is There should be visual visual feedback when feedback given when response to any response time for any action action takes more is more than 3 second. than 3 seconds. Verify that continual Continual key pad entry key pad entry do not should not cause any cause any problem. problem in application. Verify that user is able to exit from application with every form of exit User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in

18 Continual Keypad Entry 19 Exit Application

modes like application and from any Flap,Slider,End Key point. 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. Verify that when application is running and battery is low then proper message is displayed to the user. 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

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 Removal of battery at the battery at the time of time of application data call application data call is going on should not cause is going on do not interruption and data call cause interruption should be completed after and data call is battery is inserted back in completed after the device. battery is inserted back in the device. Verify that The application should not application does not consume battery consume battery excessively. excessively.

23 Battery Consumption

24 Application Start/ Restart

1. Find the Application must not take application icon and more than 25s to start. select it 2. Press a button on the device to launch the app. 3.Observe the application launch In the timeline defined Make sure that your Installed application should application is not not cause other applications causing other of device to hamper. applications of device to hamper. 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.

25 Application Side Effects

26 External incoming communicatio n infrared

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 manufacturers (or network operators) 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.

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 lets 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_r08linux_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/eclipsejava-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, youll 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 Wont recognize. So:

Go to the android installation directory->tools->Emulator. Right click on emulator icon.

Thats it! You are now ready to play with the Android on Linux. Let us know if you have any query.