Banking App Testing: Strategies, Tools, and Best Practices
Security and performance are the highest priorities regarding banking and financial services. In the first place, mobile banking is becoming increasingly popular among users, and many new companies are entering the market.
According to Statista, 1.9 billion individuals worldwide were actively using online and mobile banking services in 2020, with expectations that the number will reach 2.5 billion in 2024.
Furthermore, banking apps deal with sensitive data, which makes them an attractive target for cybercriminals. VMware Carbon Black threat data shows that attacks targeting the financial sector increased by 238% for the first three months of 2020.
Testing is essential to developing banking apps, as no gaps or omissions are tolerated. Our goal is to describe how we test mobile banking applications at Surf, and how the best testing practices help us develop great products.
Processes of Testing Banking Apps at Surf: Issues in Testing Banking Apps
Testing for banking software should ensure the smooth, error-free operation and complete security. For every new release, we run automated and manual tests and test all user scenarios to ensure that data can be updated and received from the server with no delay so that all transactions can be carried out effectively and users can get timely information about new banks products.
Banking apps usually have us handling the front end while other teams take the back end. Due to this lack of access, we have learned to work closely with the client’s side using available tools if the front-end team is delivering faster than expected.
Banking app testing challenges in banking include:
- Several integrations with third-parties
Many banking apps integrate with third-party systems, such as bill payment systems or trading accounts. QA engineers need a clear vision of how the system functions to determine what might fail and what impact that failure may have on other elements and components of the system.
- Multiple complex logic features
Testing banking apps is difficult due to the complex internal logic that must be accounted for. When a user enters a couple of digits in the finance app, a complicated internal calculation is started.
- Increasing banking apps functionality
To keep up with new regulations and to meet the demands and needs of the growing user base, banking apps must cover broad functionality and be updated regularly. Development and testing of mobile banking apps are especially challenging due to the scope and the frequent updates.
Mobile Banking App Testing: Best Practices
Our testing flow has been developed based on experiences from our native and cross-platform projects for more than 10 years. Among the industries we serve are banking and fintech.
In addition to the standard processes and procedures, we observe a few practices that help ensure app quality at every stage and save valuable time.
- An earlier analysis of design and requirements
We start reviewing requirements for completeness, correctness, and consistency by our QA team when we receive tasks for app development.
The requirements review is also accompanied by the design review so that all app states are covered, and no inconsistencies between platforms are introduced. We make sure that the requirements and the design are in agreement.
- A standard test case structure for banking applications
Surf follows test cases and checklists in their format, and it is used for all projects except a few. We developed a common structure for test cases: we similarly write them but add our creative touch inside each one.
Through the implementation of this approach, the process of app testing is improved: test reviews are accelerated, test maintenance is made easier, and project onboarding is made more transparent.
- Test component for new features
The QA team is responsible for testing parts of the app after developers are ready with them. We run the detailed component tests if this is a new feature. As with model-based tests, there is some model that shall be tested according to the test cases and checklists that have been previously written.
- Testing automation
Manual tests require more effort as the project grows in functionality, so the QA team will become unreliable.
After about six months of active development, it becomes virtually impossible to perform complete testing manually. Adding additional quality assurance staff to meet the increasing demand can be expensive.
When the project runs out of time, the minor part, which has the most bugs (80/20), will be tested. Test automation is strongly recommended for long-term projects, such as banking apps.
For regular releases, automated testing can provide quality and velocity of testing that manual testing cannot achieve in a definite period. Automated tests require no human intervention; they are carried out quickly and regularly. Adding one person to the team to write automated tests will increase coverage.
- Test automation for flutter
Surf has pioneered Flutter development. Flutter testing became a concern for us as we developed with it. Native automated tests can be written in Dart with Flutter and cover all test types as required. There are several types of Flutter tests:
- A UNIT test checks whether a specific module of a system sets the required state, for example. Interfaces are not considered. The app need not be emulated. At Surf, UNIT tests are written by developers who have a deeper understanding of the internal logic of the app. In contrast, testing automation engineers write for widget and E2E tests, which are both connected to the finished app and test cases.
- UNIT tests are on a lower level than widget tests. In Flutter, everything is a widget, so these tests can be used to emulate widgets and perform the required testing with them. Testing widgets involves launching widgets of different types and checking their functionality. A screen can contain both complete screens as well as separate elements, such as a field, a button, a checkbox, etc. We have a great advantage in this context due to our unified test case structure: mapping widget tests is easy with our test cases, which cover each element in detail.
With widget testing, bugs that are normally only visible early through manual testing can detect early. They can then be corrected promptly. Consequently, this approach reduces development time and improves code quality.
- Testing End-to-End includes loading the entire application and simulating user actions in a real infrastructure with real services, APIs, etc. For clarity, such tests are called integration tests in Flutter, but we refer to them as E2E tests.
As part of our portfolio, we developed a B2C banking app that runs on Flutter, where we implemented test automation and built the necessary infrastructure so that the bank can run the tests themselves.
End-to-end automated tests cover about 65% of the app code, emulating the user environment with detailed simulations.
This means simulating user activities such as mouse clicks, button presses, filling out forms, and switching between screens. Before releasing builds, this testing takes place – it takes time but allows a comprehensive review of the app.
- Testing before release
Before transferring the app to the client, the final test is performed to test that the app works smoothly, demonstrate the stability of new functionality, and confirm that the latest code changes have not adversely affected the existing features. As there is no time to test every element in detail, we used scenario tests to cover the entire user journey.
After completing the test, we migrate to the new version to ensure that the store versions are correctly updated.
Tools for testing 
Most of the time, our projects teams use the following banking app testing tools:
- Dart+Gherkin — tools for automating native Flutter tests;
Tooling for cross-platform automated testing: Cabash (Ruby+Cucumber), RubyMine
- Jira — project management and bug tracking software; For a similar solution, there is this alternative to Jira.
- Xray — test management software integrated with Jira; Using Charles, testing teams can see the HTTP and SSL/HTTPS traffic between their machines and the Internet;
- Figma — an editor and prototype tool for vector graphics; Analytical systems (including Firebase);
- Android Debug Bridge (ADB) — Communicate with a device using a versatile command-line application;
- Xcode — Tools for building and testing iOS applications;
A code editor optimized and redefined for building and debugging modern apps in Android Studio and Visual Studio Code; Jenkins is our CI/CD tool of choice for building and testing our apps – used to develop and test software projects continuously, making it easier for developers to integrate changes to their projects;
Nevertheless, we are ready to adapt when clients prefer a different testing workflow or another tooling or service. Additional checks and tests are always available based on client feedback, such as identifying the causes of newly discovered bugs, writing API tests, and swagger review.
Banking App Testing: In Conclusion
The Surf team just wants to highlight once again a few factors that allow the banking products we developed for our clients to be of high quality and stable:
- From project requirements to UX design and final release, our QA process covers the entire app development process;
- Knowledge of the banking and finance industry, since we have worked on numerous projects in the B2B and B2C sectors, including the first Flutter-powered banking apps;
- Precise, uniform, transparent, and easy-to-maintain test cases and checklists;
- Understanding how to write and implement automated tests that increase test coverage and save time.
