offilne App Improvements
Mobile App checklist
| 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. |
Offline App Guidelines
Browser application caching allows a manifest to be created listing pages that should be cached and made available offline. Normally, when you visit a URL, a server request is made to return the page. Setting up an application cache manifest tells the browser how it can use pages already downloaded rather than just immediately displaying an error when there is no longer a network connection.
Local Storage is a standard that retains local web app data(even when the browser is shut down) using a key/value system that works similarly to browser cookies. However, it is differentfrom browser cookies in two important ways. First, cookies are resent to the server with every HTTP request, and it would waste a lot of bandwidth to resend all offline data when the server doesn’t need it. Secondly, cookies tend to max out at around 4k of data, while local storage usually gives an application as much as 5 MB of data to work with per domain. 5 MB may not sound like much, but when used carefully, it can go a very long way in terms of offline local storage.
Local Database removes the 5MB limit of local storage and allowsdata to be indexed so that multiple properties can be queried quickly. This is only an HTML5 proposed standard at present; only Internet Explorer and Firefox have implemented it so far. Safari and Chrome use an older, deprecated system called Web SQL. This means if you need this level of functionality, there is a significant amount of extra work and complexity to supportboth standards across all major browsers. Hopefully, that won’t always be the case and major browsers will conform to the finalized HTML5 specifications.
To decide if Local Storage is good enough, consider these constraints for the app: 1. The total size of data you need to keep offline 2. The number of data items (records) you need to keep offline 3. The number of data properties (fields) you need to search within
How to choose App developement
|
Native |
HTML5 |
Hybrid |
|
|
App Features |
|||
|
Graphics |
Native APIs |
HTML, Canvas, SVG |
HTML, Canvas, SVG |
|
Performance |
Fast |
Slow |
Slow |
|
Native look and feel |
Native |
Emulated |
Emulated |
|
Distribution |
Appstore |
Web |
Appstore |
|
Device Access |
|||
|
Camera |
Yes |
No |
Yes |
|
Notifications |
Yes |
No |
Yes |
|
Contacts, calendar |
Yes |
No |
Yes |
|
Offline storage |
Secure file storage |
Shared SQL |
Secure file system, shared SQL |
|
Geolocation |
Yes |
Yes |
Yes |
|
Gestures |
|||
|
Swipe |
Yes |
Yes |
Yes |
|
Pinch, spread |
Yes |
No |
Yes |
|
Connectivity |
Online and offline |
Mostly online |
Online and offline |
|
Development skills |
ObjectiveC, Java |
HTML5, CSS, Javascript |
HTML5, CSS, Javascript |
basic testing guidelines
For UI Team :-
All Pages /Screens should be as per approved designs.
All browsers should be consider as latest versions.
1)Google chrome
2)Internet Explorer
3)Mozilla Firefox
4)Safari
5)Opera
For responsive :- consider device default browser
Atleast consider following resolutions while doing
responsive development.
1) Asus 360*640
2) Iphone 3S 320*480
3) Samsung Tab 800*1280
4) Ipad 768*1024
5) Iphone 6 375*667
6) Iphone 6 plus 414*736
7) Iphone 5 320*568
8) Kindle Fire 600*800
9) Samsung galaxy tab 600*1024
For UI desktop:-
1)IMac
2)MacBook pro
3)Small ,medium and larger screen desktops
Note:- Use less JavaScript and inline CSS, follow w3c school
and google page insights guidelines
For Mobile Team:-
1)Network related alert
2)GPS related alert
3)Device back button should be controlled
4)provide proper minimum and target OS version as
per market for apps.
For Functional Team:-
1)Concentrate on performance while implementing
functionalities.
2)Use simple queries so its execution time
will increase.
3)All basic validations should require on forms,
login page ,sign up page etc.
4)Flow control
5)cache management
6)CMS should be as per requirements.
Subscribe to:
Posts (Atom)