Checklist on how we do Android App Testing
2017
Checklist for Android App Testing
QA Specialist TestOrigen Software Testing Pvt. Ltd. 1/1/2017
WWW.TESTORIGEN.COM
Page 1
2017
Checklist on how we do Android App Testing
Functional testing: Functional Test Cases
Tested by
Tested on
Pass or Fail
Remarks
1. Check well all Android Application functionality features 2. Check all the Android Application free and paid elements 3. Test the Android Application should continue where we exited after attending call or performing text messaging 4. Test the Android Application stop conduct when related procedures are killed unexpectedly by means of Device settings 5. No information loss should happen exceptionally in e-retail or banking applications 6. No disturbance to phone calls while Android Application is in running mode 7. No disturbance to instant messages while Android Application is in running mode 8. No disturbance to key gadgets while Android Application is in running mode 9. No disturbance to social site choices like sharing and posting remarks and connections while Application is in running mode 10. Test the diverse conditions of Android application – close and open, revive and close, open, close and revive and so forth
WWW.TESTORIGEN.COM
Page 2
2017
Checklist on how we do Android App Testing
Android Device Specific Check:
Tested by
Tested on
Pass or Fail
Remarks
1. Check whether the application be installed on the device? 2. Does the application function designed/wanted if there is an incoming call? 3. Does the application works as outlined/wanted if there is an incoming SMS? 4. Does the application works as composed/wanted if the charger is connected? 5. Does the application works as outlined/wanted if the charger is detached? 6. Does the application works as composed/wanted if the device goes to resting mode 7. Does the application works as outlined/wanted if the device resumes from resting mode 8. Does the application act as composed/wanted if the device resumes from lock screen? 9. Does the application act as outlined/wanted if the device is tilted? 10. Does the application act as planned/wanted if the device is shaken? 11. Does the application carry on as outlined/wanted if a neighborhood message is originating from another application (consider: timetable updates, to-do assignment and so forth.). 12. Does the application carry on as planned/wanted if a push message is originating from another application (consider: twitter notices, whatsapp message, wordfeud welcome, and so forth).
WWW.TESTORIGEN.COM
Page 3
Checklist on how we do Android App Testing
2017
13. Does the application interconnect with the GPS sensor accurately (switch on/off, recover GPS information)? 14. Is the functionality of the considerable number of buttons or keys on the device characterized for this application? 15. Check that buttons or keys which have no characterized work have no unforeseen conduct on the application when actuating. 16. Check if there's a valid “back� button accessible on the device does the "back" button take the client to the past screen? 17. Check if there's a valid "menu" button accessible on the device, does the menu button demonstrate the application's menu? 18. Check if there's a valid "home" button accessible on the device, does the home button recover the client to the home screen of the device? 19. Check if there's a valid "Search" button accessible on the device, does this get the client to some type of search inside the application? 20. Does the application carry on as outlined/wanted if the "Battery low" message is pushed 21. Does the application act as composed/wanted if the sound on the device is turned off? 22. Does the application carry on as composed/wanted if the device is in airplane mode? 23. Will the application be de-installed from the device? 24. Does the application work obviously after re-installation? 25. Will the application be found in the application store? (Check after go-live)
WWW.TESTORIGEN.COM
Page 4
2017
Checklist on how we do Android App Testing
26. Could the application change to various applications on the device through multitasking as composed/wanted? 27. Check all touch screen positions working when a screen defender is utilized.
Android Network Specific Checks:
Tested by
Tested on
Pass or Fail
Remarks
1. Test whether the application behave according to specification if connected with the internet through Wi-Fi? 2. Test whether the application behave according to specification if connected with the internet through 3G? 3. Test whether the application behave according to specification if connected with the internet through 2G? 4. Test whether the app behaves according to specification of the application is out of network reach? 5. Test whether the app resumes working when it gets back into network reach from outside reach of the network? 6. Test whether the updated exchanges are handled accurately after re-building up connection. 7. Test Whether the application still work accurately during tethering or connected to another device 8. What happens if the application switches between networks (Wi-Fi, 3G, 2G) 9. Does the application utilize standard network ports (Mail: 25, 143, 465, 993 or 995 HTTP: 80 or 443 SFTP: 22) to interact with remote services, as a few suppliers block certain ports.
WWW.TESTORIGEN.COM
Page 5
2017
Checklist on how we do Android App Testing
Android App Specific Check:
Tested by
Tested on
Pass or Fail
Remarks
1. Has the application been tested on various kinds of gadgets and diverse forms of OS? 2. Dependability check: if the application has a rundown such as pictures in it, try scrolling through it rapidly. 3. Check if the application has a rundown such as images in it, try scrolling to before the first images or behind the last images. 4. Is downloading of the application prevented if it's greater than the OS permits downloading when connected to cellular networks? 5. Integration: does the application interact effectively to the diverse informal organizations such as LinkedIn, twitter, facebook, and so forth. 6. The application does not interfere with different applications when in foundation/multitasking mode (utilizing GPS, playing music, and so on.). 7. Can the client print from the application (if appropriate) 8. The search choice in the application shows relevant outcomes 9. Confirm most regular signals used to control the application. 10. What happens if you select distinctive alternatives in the meantime (undesired multitouch, for instance – select two contacts from the phone directory in the meantime). 11. Application name should be self explanatory 12. Test the app does limit or clean the amount of cached data.
WWW.TESTORIGEN.COM
Page 6
2017
Checklist on how we do Android App Testing
13. Reloading of information from remote services has been appropriately intended to prevent performance issues at server-side. 14. Test the application does go to sleep mode when running in the background prevents battery drainage.
Usability Testing: Ease of use Test Cases:
Tested by
Tested on
Pass or Fail
Remarks
1. Confirm application is natural to utilize. 2. Check navigation in application is functioning as expected. 3. Confirm application reacts legitimately to introduction change, squeeze to-zoom, multitouch and so forth. 4. Confirm keyboard, when activated is balanced legitimately around input components. 5. Check unmapped keys assuming any, are not working on any application screens. 6. Check battery utilization of application. 7. Check application does not slack while utilizing it. 8. Confirm the application meets ease of use prerequisites of stage. 9. Guarantee the application does not bug clients unnecessarily i.e. vibrating alerts, notifications and so forth. 10. If your application requires, guarantee there is a client manage accessible for client's assistance.
WWW.TESTORIGEN.COM
Page 7
2017
Checklist on how we do Android App Testing
Installation/Uninstallation Test Cases:
Tested by
Tested on
Pass or Fail
Remarks
Tested by
Tested on
Pass or Fail
Remarks
1. Confirm application gets installed appropriately. 2. Confirm client can uninstall application effectively. 3. Confirm application updates are legitimately installed. 4. Check prematurely ending installation does not influence different elements. 5. Check application conduct on endeavoring to install it on non-supported version/device. 6. Check application is installed appropriately from application store and from sideloading.
Entry/Exit Test Cases: 1. Check application is opened appropriately on choosing application symbol. 2. Check if application is opened legitimately from multitasking menu. 3. Check application is activated legitimately from notice, other apps(if required), voice summons, signals, on device start(if relevant) and so forth. 4. Confirm application does not take uncommon amount of time while opening. 5. Confirm client can exit application from a choice and device Home key.
WWW.TESTORIGEN.COM
Page 8
2017
Checklist on how we do Android App Testing
Performance Testing: Performance Test Cases:
Tested by
Tested on
Pass or Fail
Remarks
1. Check the behavior and performance of application under different conditions like low battery, low memory or bad network coverage area 2. Check the performance of Apps installed on different Mobile devices with various OS adaptations, memory size, processor speeds, screen size and resolutions 3. Check stability of the application when the load placed past operational break point to perceive how well it reacts 4. Number of clients get to the application at same time 5. Number of clients install the application at same time 6. Number of clients increase the edge an incentive to decide its recovery rate 7. Check the time taken to transfer and download files of different types. 8. Check the application and its update doesn't expend too high CPU and memory 9. Check the application behavior in various systems like 2G, 3G and 4G.
WWW.TESTORIGEN.COM
Page 9
2017
Checklist on how we do Android App Testing
Updates/Interruptions Test cases:
Tested by
Tested on
Pass or Fail
Remarks
1. Confirm updates are installed appropriately. 2. Check behavior of application when updates are not installed. 3. Check behavior when various updates are accessible for installed. 4. Confirm application is working appropriately after OS is installed. 5. Check application behavior when application update is prematurely ended/interrupted. 6. Check application handles interferences, for example, phone calls, SMS, phone message, introduction change and so on smoothly. 7. Check how application performs under low battery. 8. Check how application performs under low information availability and low system. 9. Check application behavior when charger is connected/disconnected. 10. Check application acts legitimately while transfer is in advance through Bluetooth/NFC. Testing Tools- latest Performance Testing Tools Suggested-Apache JMeter and LoadRunner
WWW.TESTORIGEN.COM
Page 10
2017
Checklist on how we do Android App Testing
Phone Devices Compatibility Test cases: Testing of functionality of following devices:
Tested by
Tested on
Pass or Fail
Remar ks
1. Android Smartphone (latest version) 2. Samsung Galaxy S7 3. Samsung Galaxy S6 4. Samsung Galaxy J7 5. Samsung Galaxy Core Prime 6. Samsung Galaxy Grand Neo 7. Moto E (latest version) 8. Moto E3 (latest version) 9. LG Nexux 5X (latest version) 10. HTC 828 (latest version) 11. MI 4I (latest version) 12. VIVO Y5IL (latest version) 13. Honor H30UI0 (latest version) 14. Lenevo A526 (latest version) 15. Samsung Galaxy Tab A
Testing Tools- Phone Compatibility Testing Tools Suggested- BrowserStack.
WWW.TESTORIGEN.COM
Page 11
2017
Checklist on how we do Android App Testing
Compliance Testing: Android Apps UI checks:
Tested by
Tested on
Pass or Fail
Remarks
1. Check the application UI is planned according to given OS rules 2. The icons and buttons are utilized as pre-characterized in OS rules 3. To keep controls as inconspicuous as feasible for example by blurring them out if they are not utilized for some time. 4. Make it feasible for users to backpedal to a past screen for example by including a back or cancel button 5. The principle capacity of the application should be apparent quickly. It should represent itself with no issue. 6. Use at most one activity on the screen that is featured as the no doubt for the client. 7. Limit user activities by utilizing a picker or a table view where users can choose a specific decision over an information section field where clients need to sort a decision
WWW.TESTORIGEN.COM
Page 12
Checklist on how we do Android App Testing
2017
8. In an application, the user should not have the capacity to store documents locally, outside the application sandbox. 9. In an application, the user should not be presented to the authorizations of a particular document 10. If there is a considerable rundown of information to scroll trough, give an inquiry choice over the rundown. 11. If execution is moderate, demonstrate an advance status icon ("Loading‌ "), ideally with particular message. 12. If there should arise an occurrence of "live" separating of information while the client enters his inquiry question, check the execution. 13. The presences of buttons that perform standard activities are not adjusted in the application (for example: refresh, organize, trash, Reply, back, and so forth.) 14. Try not to utilize standard buttons for different capacities then that they are regularly utilized for 15. The application should react to all adjustments in device introduction, according to the plan 16. Tapable components should be around 7x7 mm in measure; utilizing the pixel thickness of the objective gadget you can ascertain the measure of pixels. 17. Try not to reclassify signals in your application that have a standard importance. 18. Necessity to login is postponed in the application as far as might be feasible 19. If the application is stopped at a sudden time, user information should be saved locally and accessible at start-up.
WWW.TESTORIGEN.COM
Page 13
2017
Checklist on how we do Android App Testing
20. Users should be warned of the results of erasing an archive 21. Keyboard adjusts to expected contribution (for example numbers/letters when anticipated). 22. Test whether the inactive buttons clearly distinguished from active buttons?
Accessibility Testing: Android Accessibility Test cases:
Tested by
Tested on
Pass or Fail
Remarks
Tested by
Tested on
Pass or Fail
Remarks
1. Check the application is easy to use for incapacitate individuals in case meant to 2. Content to Speech converter works precisely 3. High Contrast Support to guarantee visibility 4. Application is worked according to W3standards
Security Testing: Security Test cases: 1. Check application does not disregard security while running in a different user account. 2. Confirm authorizations required by application. 3. Check session is appropriately kept up by application.
WWW.TESTORIGEN.COM
Page 14