• Sophia Brooke, Project Manager at SoftwareMill


• 24.04.2018 09:15 am
undisclosed

The number of smartphones users worldwide is expected to grow from 1.8 billion in 2015 to an estimated 2.87 billion users in 2020 according to Statista. In the meantime, the number of people who have a bank account is expected to rise only by 700 million worldwide, compared to 2015, according to a Gallup report. It is clear that by 2020 the smartphone user market will be much higher than that of bank account holders. With these statistics in mind, it becomes clear that mobile banking apps users will double and account for a quarter of the world's population by 2019.

There is currently a migration from traditional bank services from the 80s and 90s to mobile banking services and apps. Banks understand that they need to create high-performance and reliable apps to conserve their market share and meet client expectations. The high performance and usability expected of the apps must come from robust and versatile mobile applications tests.

When we talk about mobile banking apps, the first word you think of is security. In almost all testing scenarios for banking applications, QA developers are inclined to focus on ensuring the app’s security. Cybercrime has made security the most significant concern of retail banking apps.

However, besides security, there are other key areas that many testers on the development team have to pay attention to with standard app testing methods such as functionality, security, and performance.

Domain-Specific Test Data

Mobile bank apps use confidential data like phone numbers, addresses, DOB or bank account information. The personal information of customers can’t be exposed in the public domain. Most countries have stringent regulatory requirements to protect personal data. Those regulations are often significant challenges for QA teams in obtaining production-like data, even if they are QA outsourcing teams or in-house development teams. 

An answer is an approach that combines data masking and synthetic data creation, a solution that can successfully handle this problem. Through data masking, the account related information is masked by automated scripts. The masked data is then inserted into a cut-down version of the database for testing purposes. Similarly, synthetic test data is created in a controlled test environment after understanding the business informational flow.

Controlled vs. Real Environment

To anticipate all the associated risks that mobile banking apps are being exposed to in a real environment, test plans should clearly highlight the differences between the two. Functional, data, technical or any other variations between production and test environments should be diminished in advance.

In most banking applications, data transfer (file transfer) across different systems in production is generally automated through FTP or FTPS; it is very hard in a test environment to simulate any data transfer delay that sometimes happens in a production environment. Scenarios such as delay in transfer, transfer of the same file more than once or a new file overriding the existing data must be replicated in a test environment.

In mobile apps, a delay in transfer might lead to significant customer dissatisfaction as smartphone users expect a real-time response from apps. These kinds of scenarios need to be taken into account and the risks quantified and handled or highlighted clearly in test plans.

Resources

Mobile banking apps have to handle large volumes of data and with the limited resources that a smartphone or a tablet has to offer this is a challenge for developers. Even small operations can generate substantial data volume. These include the log-in data, user location and all the actions that a bank client made while using the app. Banks need to have enough hardware resources to ensure that the app is running smoothly and the user has a pleasant experience. The end user will not use an app with compromised performance even if the underlying functionality works as expected. Also, it is important that the app does not consume a significant share of the mobile device’s resources. Most users pay attention when they install a new app, keeping in mind the chance that it could slow down their mobile or tablet.

Recoverability

All apps are crash at some point or under challenging conditions. A bank app should quickly recover from some point during transaction interruptions or unexpected crash scenarios.

Large and various amounts of verifications of how the application handles a transaction during a power failure (i.e., the battery dies or a sudden manual shutdown of the device) should be conducted by the testing team. This way, developers can predict the percentage of data that can be recovered and the precise point where no recovery is possible.

The validation of the process where the connection is suspended is also critical. The system needs to re-establish for recovering the data directly affected.

The recovery process is equally as important as security because without the ability to retrieve data, an app can frustrate the user and cause bad experiences, which leads to them uninstalling the app.

Versatility

In August 2015, there were more than 24,000 Android mobile device models according to OpenSignal. Although Apple has fewer models, the mobile device fragmentation is still huge. Attempting to test all combinations is often a very costly and ineffective exercise on real devices, as new combinations are regularly introduced to the market. So, the problem should be solved in another manner. Analyzing data for geographical regions about usage patterns of brands for mobile devices and platforms is a good starting point. For example, in North America, the focus may be on high-end iOS/Android phones, while in Latin America countries, the application may be tested on low-end Android phones.

Collect data from your marketing research teams and know what your users are doing with the application. The development team should discover patterns and trends related to app users and focus testing action on the most used platforms and devices.

Conclusion

App testing teams need to be well briefed and closely follow a strategic and technical direction to ensure the success of a future product. Probably the future will bring even more areas that QA development teams should focus on, but those areas remain in the hands of customers for the moment. Some current critical areas will become secondary in the testing process, as the mobile bank apps market grows and develops, but security will not be one of them. 

This article originally appeared at: Finextra.com