Functional Testing Scenarios for Mobile Apps

Functional testing is an important checkpoint before releasing a mobile application. In this article, Dmitriy Radchenko shares a checklist of some of the basic points that will be common among mobile applications when you need to perform functional testing.

Author: Dmitriy Radchenko, TestMatick, http://testmatick.com/

Mobile application functional testing usually covers user interaction testing, as well as testing of transactions. Important factors for this type of testing are:
1. The type of application defined by its business functionality (banking, gaming industry, social networks, education).
2. The target audience (user, company, educational environment).
3. The distribution channel for the application (for example, App Store, Google Play or direct distribution).

Mobile Application Testing

In simple terms, we check whether the application performs the expected functions, which are usually described in the specification or dictated by the business processes.
Therefore, functional testing can be carried out in terms of requirements. In this case, test cases are formed. Technical specification based on the business processes is used for its creation. Once this is done, so-called use cases for mobile testing are created which describe scenarios for daily or permanent use of the application.

The basic functional testing scenarios:

  1.  Check the correctness of the mandatory fields.
  2.  Make sure the required fields are not displayed on the screen as optional.
  3. Verify that the application operation during the running/exit meets the basic requirements.
  4. Ensure the application goes into the background in the case of an incoming call. You will need one more phone to do this.
  5. Check if the phone can store, receive and send messages while the application is running. To do this you will need another phone from which you can send a message to the tested device with the already running application.
  6. Make sure the device works in multitask mode when necessary.
  7. Check how the necessary options work with the social networks – Share, Publication, Navigation.
  8. Ensure the application supports payment transactions through the payment systems Visa, Mastercard, Paypal, etc.
  9. Verify the adequacy of the page scrolling scenarios.
  10. Check the proper navigation presence between important application modules.
  11. Make sure that the number of rounding errors is minimal.
  12. Сheck for error messages, for example, «Network error. Please, try again later» in case of incorrect network operation.
  13. Ensure the installed application does not prevent the normal operation of other applications and does not consume their memory.
  14. Check if the application is able to return to the state in which it was before the suspension (for example, hard reset or system failure).
  15. The program installation must take place without significant errors, provided that the device meets the system requirements.
  16. Make sure the application automatic startup is correct.
  17. Check how the application works on all the devices of the 2G, 3G and 4G generations.
  18. Perform regression testing to identify new software errors in existing and already modified areas of the system. Additional conducting of all the previous tests to verify the program behavior after the changes.
  19. Ensure the availability of user manual.

The system often possesses a lot of functions and it is not always possible to check them all. Thus, certain test cases and user cases are usually prioritized before the start of functional testing, regulate the time in accordance with the priorities and then pay attention to the most important ones. It is quite difficult to select some standard scenarios for functional tests due to the variety of applications but it is possible to identify frequently occurring modules, compose test cases for them and then to use it, modifying for specific requirements.

For each function, it is necessary to check both positive scenarios and negative ones. A scenario is considered positive when the user achieves a goal (create item, sends a message and so on). In a negative scenario, an error occurs at some of the steps and the goal can not be achieved. For example, consider login / logout and creating a contact (section, user, or any other item). Standard login / logout can include such options:

  • registration: with a login and password, without a password, through the social network, etc.;
  • authorization: with a login and password, through the social network, etc,;
  • password recovery;
  • logout: standalone, after the session, etc.

Positive scenarios:

  • Registration in the application is available with all the methods described in the terms of a technical specification.
  • You can register by filling in only the mandatory fields.
  • You can register by filling in all the fields completely.
  • It is possible to log in to the application after the registration. In this case, the entered data is correctly stored in the profile (e-mail, password, personal information, etc.).
  • Registering on one device, you can log in to another – the data is available and correctly stored on the server and available.
  • Logout works correctly.
  • Password recovery works correctly.

Negative scenarios (the most obvious):

  • Re-registration for the same e-mail with the same login is not available.
  • Registration without filling in the mandatory fields is not available.
  • Registration, if all the fields are left blank, is unavailable.
  • Registration, if the format of the entered data does not meet the requirements, is not available.
  • Authorization with empty fields is not available.
  • Authorization with a wrong / deleted / blocked login is not available.
  • Authorization with incorrect password is not available.

Creating a contact. It is logical to assume that if a user creates a contact, it should be possible to view, edit and delete it. This is the basic set of functions an item can possess.

Positive scenarios:

  • Creating, editing, viewing and deleting of the contacts are available.
  • Creating a contact with the minimum data set is available.
  • Creating a contact with the maximum data set is available.
  • When creating, all the data types, described in the technical specification, are processed correctly.
  • Once created, a contact is available for viewing.
  • The change takes into account mandatory fields / data / elements. Saving the contact without them is not available.
  • Once deleted, the contact is no longer available.

Negative scenarios:

  • Creating two identical contacts is not available (it can be a positive scenario).
  • Creating a contact with a missing required elements / data is not available.

I can also add the user interface checking to the functional testing.

  1. Screen verification for matching the layouts.
  2. Checking the work of native gestures: swipe, multi-touch etc. The application should react to them in a certain way.
  3. Checking the states of the elements: buttons change the color if pressed; lists are collapsed and unfolded, so on.
  4. Verification of localization, if it is stated in the application. It is important to pay attention to layout. A lot of names in other languages are much longer than in English or Russian.

About the author

Dmitriy Radchenko is QA Team Lead at TestMatick. He is experienced in testing web based applications (including SaaS based applications), content management systems, databases as well as mobile based client-server applications on major platforms like iOS & Android.