Thursday, March 31, 2011
Monday, March 28, 2011
Thursday, March 24, 2011
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. |
Smartphones and Tablet
(MWC @ 2011) wrapped up last week in Barcelona, and there were so many smartphone and tablet offerings at the show, you could get information overload just trying to make sense of it all.
Here’s an infographic that won’t necessarily show you which products were the best, but will certainly let you know which ones had gadget aficionados the most intrigued. Webtrends sorted it out for us, measuring the buzz of the event by calculating mentions on Twitter, blogs and other social media between February 13 and February 17.
Even though Samsung’s Galaxy Tab 10.1 was out-buzzed by the LG Optimus Pad, with the help of its second-generation Galaxy S II smartphone, Samsung was the top most-buzzed brand during MWC week, just like it was during CES 2011. Coming in second was Google (not surprising, due to all the talk about Android on smartphones and tablets), with HTC in third.
Breaking it down into days, Samsung and HTC fought it out on Monday for the lead buzz spot, with Samsung victorious at 32%. Tuesday, HTC fought back with with its 7-inch 1.5GHz HTC Flyer tablet, winning the day with 30.8% of the buzz.
Notice that while tablets grabbed 47.7% of the buzz, all those iPad competitors were still eclipsed by the 52.3% buzz for smartphones, which in the past have been the only buzzed-about device at MWC:
Here’s an infographic that won’t necessarily show you which products were the best, but will certainly let you know which ones had gadget aficionados the most intrigued. Webtrends sorted it out for us, measuring the buzz of the event by calculating mentions on Twitter, blogs and other social media between February 13 and February 17.
Even though Samsung’s Galaxy Tab 10.1 was out-buzzed by the LG Optimus Pad, with the help of its second-generation Galaxy S II smartphone, Samsung was the top most-buzzed brand during MWC week, just like it was during CES 2011. Coming in second was Google (not surprising, due to all the talk about Android on smartphones and tablets), with HTC in third.
Breaking it down into days, Samsung and HTC fought it out on Monday for the lead buzz spot, with Samsung victorious at 32%. Tuesday, HTC fought back with with its 7-inch 1.5GHz HTC Flyer tablet, winning the day with 30.8% of the buzz.
Notice that while tablets grabbed 47.7% of the buzz, all those iPad competitors were still eclipsed by the 52.3% buzz for smartphones, which in the past have been the only buzzed-about device at MWC:
Tuesday, March 22, 2011
iPhone Slower Than Android on Web, Report Says
Android phones whisk users across the web in two-thirds the time that the iPhone takes, according to a study that compared the two top mobile OSes’ performance when downloading web pages.
(See update below for caveats about the study, and Apple’s rebuttal.)
The study, conducted by mobile-website–optimization company Blaze.io, involved more than 40,000 downloads of web pages belonging to the Fortune 1000 companies. The iPhone took 52 percent longer than Android to render full web pages. On average, Android phones took 2.1 seconds to render non–mobile-optimized web pages, while the iPhone took 3.2 seconds.
Android bested the iPhone on site-loading time a whopping 84 percent of the time.
The test included the Samsung Nexus S (Android 2.3), Samsung Galaxy S (Android 2.2), iPhone 4 (iOS 4.3) and iPhone 4 (iOS 4.2). Pages were loaded using a strong Wi-Fi connection, and each device loaded each Fortune 1000 website three times.
Oddly, the study found that the much-touted JavaScript improvements in the latest versions of Android and the iPhone had little real-world effect on these web pages.
“Our conclusion is that JavaScript performance doesn’t impact an average page load time,” the company wrote in the study. “Apparently, JavaScript is already so optimized that it doesn’t play a big role in the time it takes to load a page. It’s likely that rich AJAX applications benefit from these improvements, but users should not expect their casual web surfing to move faster.”
(See update below for caveats about the study, and Apple’s rebuttal.)
The study, conducted by mobile-website–optimization company Blaze.io, involved more than 40,000 downloads of web pages belonging to the Fortune 1000 companies. The iPhone took 52 percent longer than Android to render full web pages. On average, Android phones took 2.1 seconds to render non–mobile-optimized web pages, while the iPhone took 3.2 seconds.
Android bested the iPhone on site-loading time a whopping 84 percent of the time.
The test included the Samsung Nexus S (Android 2.3), Samsung Galaxy S (Android 2.2), iPhone 4 (iOS 4.3) and iPhone 4 (iOS 4.2). Pages were loaded using a strong Wi-Fi connection, and each device loaded each Fortune 1000 website three times.
Oddly, the study found that the much-touted JavaScript improvements in the latest versions of Android and the iPhone had little real-world effect on these web pages.
“Our conclusion is that JavaScript performance doesn’t impact an average page load time,” the company wrote in the study. “Apparently, JavaScript is already so optimized that it doesn’t play a big role in the time it takes to load a page. It’s likely that rich AJAX applications benefit from these improvements, but users should not expect their casual web surfing to move faster.”
Android Runtime
Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool. The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.
A real time scenario where android can be used
Imagine a situation that you are in a country where no one understands the language you speak and you can not read or write. However, you have mobile phone with you. With a mobile phone with android, the Google translator translates the data of one language into another language by using XMPP to transmit data. You can type the message in English and select the language which is understood by the citizens of the country in order to reach the message to the citizens.
Subscribe to:
Posts (Atom)