Mobile testing
Mobile Testing admin-GraspMobileDevelop  

Mobile testing

This article will be useful to everyone who is involved in the development process, both from the agency and from the client: managers, designers, developers, testers. It covers the main features of testing mobile applications. In my comments, I will reveal in more detail the nuances of each type of testing, as well as give several examples of use.

One of the following types will suit you, depending on what purpose you are pursuing:

  • functional testing;
  • performance testing;
  • security testing;
  • usability testing (usability testing);
  • compatibility testing;
  • recovery testing.

 

Functional testing

Functional testing of mobile applications usually covers user experience testing as well as transaction testing.

 

Factors important for this type of testing:

  1. The type of application defined by its business functionality (banking, gaming, social media, education).
  2. Target audience (user, company, educational environment).
  3. The channel through which the app is distributed (for example, App Store, Google Play, or direct distribution).

 

In simple terms, we check if the application performs the expected functionality, which is usually described in a specification or dictated by business processes.

Therefore functional testing can be done based on requirements. In this case, test cases are formed, for their creation, a technical task based on business processes is used. After that, so-called use cases are created. They describe scenarios for daily or continuous use of the application.

 

Basic functional test scripts:

  1. Check the correctness of the required fields.
  2. Make sure required fields are displayed differently than optional fields.
  3. Make sure that the application runs at startup / exit time meets the basic requirements.
  4. Make sure the app goes into the background in case of an incoming call. To do this, you will need another phone.
  5. Check if the phone can store, receive and send SMS messages while the application is running. To do this, you need another phone from which you can send a message to the device under test with the application already running.
  6. Make sure the device is multitasking when needed.
  7. Check how the necessary options for working with social networks function – Share, Publish, Navigate.
  8. Make sure that the application supports payment transactions through payment systems Visa, Mastercard, Paypal, etc.
  9. Check the adequacy of the page scrolling scripts.
  10. Check if there is proper navigation between important application modules.
  11. Ensure that the number of round-off errors is minimal.
  12. Check for error messages such as “Network error. Please try again later ”in case of network malfunction.
  13. Make sure that the installed application does not interfere with the normal operation of other applications and does not eat up their memory.
  14. Check if the application is capable of returning to the state it was in before being suspended (for example, a hard restart or a system crash).
  15. The installation of the application should proceed without significant errors, provided that the device meets the system requirements.
  16. Make sure that the automatic launch of the application works correctly.
  17. Check how the app works on all devices of 2G, 3G and 4G generations.
  18. Perform regression testing to identify new software errors in existing and already modified areas of the system. Additional conduct of all previous tests to verify the behavior of the program after the changes.
  19. Make sure there is a user manual available.

The system often has a large number of functions, and it is not always possible to test all of them. Therefore, before starting functional testing, they usually prioritize certain test cases and use cases, allocate 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 you can select common modules, compose test cases for them and use them in the future, modifying them for specific requirements.

For each function, both positive and negative scenarios need to be tested. The scenario is considered positive if the user eventually reaches his goal (creates an item, sends a message, etc.). Negative, respectively, on the contrary – at some of the steps an error occurs, and the goal cannot be achieved.

For example, consider login / logout and creating a contact (section, user, or any other item). Standard login / logout may include options:

  • registration: with a login and password, without a password, via social networks, etc .;
  • authorization: with login and password, via social networks, etc .;
  • password recovery;
  • logout: independent, after session expiration, etc.

Positive scenarios:

  • Registration in the application is available in all ways described in the TOR.
  • You can register by filling in only required fields.
  • You can register by filling in all the fields completely.
  • After registration, you can log in to the application. In this case, the entered data is correctly saved in the profile (e-mail, password, personal information, etc.).
  • After registering on one device, you can log in to another – the data is correctly saved on the server and available.
  • Logging out is working correctly.
  • Password recovery works correctly.

Negative scenarios (most obvious):

  • Repeated registration to the same e-mail, with the same login is not available.
  • Registration without filling in the required fields is not available.
  • Registration, if all fields are left blank, is not available.
  • Registration is not available if the format of the entered data does not meet the requirements.
  • Authorization with empty fields is not available.
  • Authorization with wrong / deleted / blocked login is not available.
  • Wrong password authorization is not available.

 

Create contact.

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

Positive scenarios:

Create, edit, view and delete contacts are available.

Creating a contact with a minimal set of data is available.

Creating a contact with the maximum data set is available.

When creating, all data types described in the TK are processed correctly.

Once created, the contact is available for viewing.

The change takes into account required fields / data / elements. It is not possible to save a contact without them.

Once deleted, the contact is no longer available.

Negative scenarios:

Creating two identical contacts is not available (this could be a positive scenario as well).

Contact creation with missing required elements / data is not available.

Here, as functional testing, I will include checking the user interface:

Checking screens for matching layouts.

Testing the work of “native” gestures: swipe, multitouch, etc. – the application must react to them in a certain way.

Checking element states: buttons change color if pressed; lists collapse and expand, etc.

Localization check, if such is stated in the application. It is important to pay attention to the layout – many names in other languages ​​are much longer.

Performance testing

Also known as load testing. This is automated testing that simulates the work of a certain number of users of a shared resource.

Main goals:

  • Determine the number of users who can simultaneously work with the application.
  • Check how the application behaves when the intensity of some operations increases.
  • Check the performance of the application with many hours of use at an average load.
  • Check application behavior under stress conditions.
  • Check the work in the conditions of the “grown” database – how quickly the queries are executed.

The main purpose of this type of testing is to make sure that the application works acceptable under certain performance requirements: access to a large number of users, elimination of an important infrastructure element, such as a database server, etc.

The main scenarios for testing the performance of mobile applications:

  1. Determine if the application performs the same under different network conditions.
  2. Determine if the current network coverage is capable of supporting the application at various levels of user load.
  3. Determine if the existing client / server configuration provides optimal performance.
  4. Find various application and infrastructure bottlenecks that are slowing down application performance.
  5. Check if the application response time meets the requirements.
  6. Assess the ability of the product and / or hardware to handle the planned load.
  7. Estimate how long the battery can keep the application running under the planned load.
  8. Check the operation of the application in cases of switching from a Wi-Fi network to a mobile 2G / 3G network and vice versa.
  9. Verify that each of the processor memory levels is performing optimally.
  10. Make sure that battery consumption and memory leaks are within the normal range, and that various resources and services, such as GPS navigation or the camera, are working properly.
  11. Check the durability of the application under severe user load conditions.
  12. Check network efficiency while the device is in motion.
  13. Check the performance of the application if it works with an unstable internet connection.

Security testing

It is a testing strategy used to verify the security of the system, as well as to analyze the risks associated with providing a holistic approach to protecting the application, attacks by hackers, viruses, and unauthorized access to confidential data.

The main purpose of this type of testing is to ensure the security of the network and application data.

Following are the key steps to check the security of a mobile app.

  1. Make sure that the data of application users – logins, passwords, bank card numbers – are protected from network attacks of automated systems and cannot be found by brute force.
  2. Ensure that the application does not provide access to sensitive content or functionality without proper authentication.
  3. Ensure that the application’s security system requires a strong password and does not allow an attacker to get hold of the passwords of other users.
  4. Make sure the session timeout is adequate for the application.
  5. Find dynamic dependencies and take steps to protect these vulnerabilities from attackers.
  6. Protect the application from SQL injection attacks.
  7. Find cases of unmanaged code and fix its consequences.
  8. Verify that certificates have not expired, regardless of whether the Certificate Pinnig application is using or not.
  9. Protect your application and network from DoS attacks.
  10. Analyze data storage and validation requirements.
  11. Provide session management to protect information from unauthorized users.
  12. Check all cryptographic codes and correct errors if necessary.
  13. Ensure that the business logic of the application is protected and not vulnerable to external attacks.
  14. Analyze the interaction of system files, identify and correct vulnerabilities.
  15. Check protocol handlers (for example, whether they are trying to reconfigure the default landing page using malicious floating frames).
  16. Protect the application from malicious attacks on clients.
  17. Protect the system from malicious injections while the program is running.
  18. Prevent possible malicious consequences of file caching.
  19. Prevent unreliable data storage in the device keyboard cache.
  20. Prevent possible malicious actions of cookies.
  21. Ensure regular data security controls.
  22. Examine user files and prevent their possible malicious influence.
  23. Protect the system from buffer overflows or memory integrity violations.
  24. Analyze various data streams and protect the system from their possible harmful effects.

Leave A Comment