/ mobile-testing

7 steps Android Developers take during mobile QA testing

By DeviQA on Mon May 15 2017 00:00:00 GMT+0000 (Coordinated Universal Time)

7 steps Android Developers take during mobile QA testing

The mobile users expect that the applications installed by them are simple, intuitive, work always and everywhere without fail. If the expectations are not justified, then the user simply installs a similar application from another author, which in the field of mobile development is always enough. Therefore, the quality of the application is one of the main factors of its popularity.

To understand the features of qa mobile testing, one should take into account the moments that fundamentally distinguish mobile applications from desktops: OS specificity for mobile platforms, various device manufacturers and component configurations, the functionality of smartphones, and so on.

According to these features, the approach to the development of applications and, in particular, mobile qa testing is quite different from the desktop. There are many additional important nuances and requirements that need to be tested during android mobile testing.

Lets know how to test android application on mobile. Below are the moments that must be tested providing android testing.

#1 Screen size and touch-interface:

All elements must be of such size that the user can uniquely get on them.

- Absence of empty screens in the application - the user should not be in a situation in which it is not obvious what is happening and what to do.

- It is necessary to check the repeated rapid tapping the button - often in this case, the application may fall. You should also check multi-touch - tapping several buttons at the same time.

- It is necessary to check the presence or absence of "native" gestures (pinch-to-zoom, double tap).

Screen size and touch interface

#2 Device resources:

- Memory leaks. Especially it can manifest itself on windows, with a lot of information (long lists as an example), during tasks with long workflow (when the user does not leave the application for a long time), with incorrectly working image caching.

- Handle memory outages for operating the OS when the application is active or running in the background.

- Lack of space to install or run the application.

- The absence of some functions supported by the application (3G, NFC, SD-card, etc.).

- Install or transfer the application to the SD card.

Device Resources

#3 Different screen resolutions and OS versions:

There are a lot of screen resolutions used in Android, much exceeds the IOS and Windows Phone - it is desirable to execute android application testing on all popular used screen resolutions at least.

- Retina and conventional screens. On the retina screens, the interface elements and text are displayed smaller. Pictures for high-DPI screen can get into the low-DPI version and then will be too big.

- Adaptation the application to portrait and landscape orientations of the device.

- OS versions. The application should not be installed on unsupported devices. A check is required for all available supported devices.

- Support for the necessary media files with this model and the OS.

Different screen resolutions and OS versions

#4 Application response to external interrupts

- Incoming and outgoing SMS, MMS, calls, notifications of other applications.

- Turn off the device, remove the battery, discharge the device, or remove SIM card

- Go to standby mode (including with password protection). Change the orientation of the device in standby mode.

- Disconnecting and connecting the wire.

- Disable and enable network, Bluetooth, airplane mode, GPS, NFC, Wi-Fi

- Loss of communication with the server or proxy (connection is, but the packets do not reach).

- Disconnecting and connecting an SD card, additional devices such as a physical keyboard or headset.

- Charging the device.

- Work with the accelerometer, magnetic compass etc.

Working with a physical keyboard (if there are such models in the list of supported models).

Application response to external interrupts

#5 Paid content inside the app:

- Correspondence of the price and content declared in the application, what a user gets.

- Purchase recovery (application update).

Paid content

#6 Internationalization (check both: in portrait and landscape mode!):

- Checking the correctness of the translation.

- Checking that all the inscriptions come in the appropriate forms, buttons, etc.

- Checking the formats of dates, delimiters in numbers, specific features of localization (like a space before the question mark in the French, upper indices "o" and "a" in ordinal numerals in Spanish and other non trivial moments).


#7 Constant feedback with to a user:

- All pushable elements must have a pressed state (response to the action) - due to this the user will always see whether or not the pression has happened. In Android-applications, the elements can have one more state - focused.

- The reaction of the buttons on pressing. The speed of the response of the elements should be quite high. It is advisable to use the weakest devices among the supported ones to test this.

- Messages when downloading content or progress bar.

- Messages for network access failure, BT, GPS, NFC, Wi-Fi.

- Having clear messages when trying to delete important information.

- The presence of a screen or message at the end of the process or game.

- Presence and synchronicity of sounds or vibrations with notifications and other events on the screen.

At the end of development of Android app - usually is being executed the acceptance testing. It also includes such aspects:

- The application installation file (.apk) must be consistent with Program Policies.

- In the case of publishing an updated assembly, it is advisable to follow the order of version control (for example, the adopted version numbering order).

- The application must not conflict with the UIG document.

- Also for individual application stores (Amazon App Store, Samsung Apps, Yandex.Store and the like) there may be their own requirements and guidelines.

The issues facing the mobile app test engineer during mobile quality assurance.

The first and most important point is that testing mobile phones will take longer than you expect, even if you already assume that it will take more time. (Peter-Paul Koch).

Mobile devices run on batteries, and therefore are forced to automatically go into standby mode after a couple of minutes of inactivity. This means that you will have to turn on the phone before each test, if you test on the several phones at the same time, it takes a decent amount of time. Of course, on many devices it is possible to disable automatic locking (or at least make the disconnect time quite large), but it is desirable to perform android app testing on the most common OS settings of among users.

The transition to the standby mode is especially unpleasant when using some automated testing systems that require time for data processing (for example, the removal and comparison of screenshots). It is possible that the phone will go into standby mode right in the middle of the test.

To test for weak or missing Wi-Fi and 2G/3G/4G signals, you usually have to build a laboratory, or use various tricks like foil boxes.

Some time when a user update the application all his data is lost. So, it is important to check for an adequate update (all user data are saved, etc.).

Usually, all tests are performed on one device, then on another, and so on. This is not as optimal as testing on all devices at the same time, since it does not allow you to simply compare the output and performance of tests on devices, however, in view of the difficulties described above, this is the most economical method.

The video below describes how to test android app by using Appium.