The era of digital advancement we live in these days does not find all the industries equally well. Being highly dependent on technology, the financial and banking industry is frequently forced to deprive its operations of innovation in the favor of stable performance expected by users. Is there a way out for banks and other financial entities stuck with outdated software solutions? Yes, and it is called software quality assurance for banking.

How can banks achieve high-tech progress without compromising the continuous crash-free consumer service through software testing? Answered in today’s guide to banking application testing.

What are banking applications?

A banking domain application is a digital product built and owned by a financial institution to give their consumers the control over electronic operations related to finance, like transaction processing, account management, and easy access to one’s deposit. The term banking/finance app is also used to name any software system in the BFSI (banking, financial services and insurance) industry, at times including CRM and ERP programs for operational management, corporate banking, and user delivery channels.

Given that banking and finance digital products are built for a few very specific and rather complex operations, which makes them prone to errors mostly unseen in other types of software. This requires a non-standard approach to banking domain application testing, which we’re discussing further in this article, alongside the unwanted situations a financial institution might face if the QA process is neglected.

Interesting bugs in banking applications

Online banking system crash due to emojis

Why type all those characters if a single emoji does the trick? If you didn’t skip over the title of this section, you’ll know why.

In May 2016, a client of a certain bank decided to use emojis to name their savings accounts: 💸 instead of “Tax Money” or 🏠 for “Mortgage”. While the client was enjoying the new, concise, and cute name in the banking application, the bank itself experienced the system crash. After investigating everything that could potentially affect the performance of their CRM software, the technical support team found out that it was the emoji that their system couldn’t recognize. After changing the account name, the team was able to get the CRM back on track again.

A thorough examination of this issue showed that financial applications aren’t the only type of software that can break because of emoji figures. Putting them in the names of your Wi-Fi network or Bluetooth device can reportedly cause problems when connecting to these interfaces. This is because the character encoding standards that most software systems rely on were created way before people knew what emojis are. So, if not tested in advance and extended intentionally, representational systems like ASCII (American Standard Code for Information Interchange) and EBCDIC (Extended Binary Coded Decimal Interchange Code) won’t support funny faces or even diacritical marks such as ë or é.

Global banking giant’s app can’t cope with user load

Surprisingly to many, large powerful corporations are no stranger to software glitches. Namely, one of the largest financial companies in the world HSBC has experienced difficulties keeping its mobile application live numerous times. For example, in November of 2018, HSBC mobile app crashed during Black Friday ― the largest global sales of the year. Thousands of people were unable to enter their accounts, therefore could not take advantage of the limited-time offers from online shops. Poorly functioning apps are always irritating, but when it comes to a program that enables you access to your own money, mild frustration can turn into righteous fury really fast.

There could be many reasons why banking software might fail, but when this happens during the long anticipated sales (as with HSBC), we can surely tell the application just couldn’t stand the user load. Such events will always be a challenge for banks due to the wave of transactions, so in our humble opinion, this is something the HSBC online-banking test team should have foreseen. Both stress and load are rather unexpected issues, yet they can (and should) be planned and assessed by R&D teams. The corporation prefers not to publicly discuss other reasons why their app eventually stops working, as opposed to their users, who were very vocal on social media when it came to complaining on application performance.

AI ruins credit scoring systems

It’s hard to imagine that in the time when people just won’t stop talking about all the amazing benefits of artificial intelligence and machine learning, some industries can actually deteriorate when adopting them.

Initially, AI and its applications for banking were aimed at making credit risk assessment faster and less biased by decreasing the level of human involvement. But as practice has shown, AI is influenced by the information it is fed, and the bias that was meant to be expelled from the system becomes part of the AI’s decisions. For example, the FICO score system which is used to measure consumer credit risk across the United States continuously works towards making the scoring process more transparent and gender- and race-neutral. However, given that artificial intelligence algorithms do not differentiate the discriminatory factors from fair-minded ones, the correlations they produce inevitably include the information about ethnicity, gender, social group, etc. Furthermore, there are also many small details like grocery preferences and music taste that end up in the AI-powered credit score analysis. All that is really fascinating, but the real question is, do we really need all that information to make the right lending decision? Finance practitioners admit that ML and AI applications for credit scoring rather create bias than help to prevent it.

Another issue the banking industry has with AI is the lack of explainability. All consumers who weren’t approved for loan, have the right to get an extensive explanation of the refusal. This information is nearly impossible to gather because of the unknown patterns a machine learning model follows to analyze consumer data. While making the rating procedure faster for credit managers, AI decreases its transparency for end users thereby affecting the level of trust to financial institutions in general.

Less eye-catching bugs are still there

The aforementioned software errors made their way to the news, yet this doesn’t mean character recognition, load stability, and control over AI extensions are the only things you have to think of when testing your banking application. There are thousands of less headline-worthy bugs that happen in finance software daily, and only a thoroughly planned and well executed QA process can help your business deal with each of them in advance. That being said, we’re moving to more aspects to consider when working on a banking application.

Why is it important to test banking applications?

The importance of banking application testing seems like a no-brainer, given that we all use banking apps and expect a spotless experience. However, when you are about to do any form of banking testing, you need to know why you’re doing it at all. Here are the biggest reasons to invest in testing banking and finance applications:

• Faciliatating a positive user experience. While using banking solutions is a necessity for many users, they will still choose the most user-friendly application for their financial needs. Testing for the banking domain focuses, among other things, on UI and UX aspects of the solution.

• Creating a secure user environment. When using a financial software product, users expect their data to be handled with maximum care, while even the smalles security-related controversy can completely tank the reputation of the business. Extensive QA helps avoid that problem.

• Ensuring compliance with industry regulations. The banking industry is one of the most regulated ones, and in addition to the basics like GDPR and ISO/IEC 27001 regulations, there are often new ones introduced by authorities. Continuous testing performed by an experienced team ensures full compliance.

• Checking the way different systems integrate. This may not be a fact many regular users are familiar with, but banking & financial solutions often consist of different modules with different objectives. Thorough software testing can verify the correct operation of these modules on their own and as part of a bigger picture.

• Maintaining proper performance in every scenario. Like most software solutions, banking apps are prone to spikes in load and other scenarios that are not that easy to account for. However, a seasoned team of QA experts can project every likely and unlikely scenario, making sure your app reacts accordingly.

Things to consider before you test banking domain applications

Select a banking software testing platform

The more complicated an app’s functionality is, the more complex and layered the testing process of it is going to be. That’s why you definitely need to choose the right testing management platform to maintain all the controls over your QA activities in one place. Namely, through a testing platform you and your QA team will be able to:

• Reach maximal test coverage
• Use time and resources more efficiently
• Track the test cases execution
• Balance testing on different operating systems
• Maintain concise testing documentation
• Decrease the level of work-associated stress in the team by organizing the process well.

With banking and financial programs especially, this choice has to be well thought out. This is because such software solutions are very feature-rich therefore have a complex architecture. To organize the testing process, you’ll have to use multiple tools, environments, and devices, which means it would be better to select a testing platform that can cover multiple activities and integrate with many other programs at once. Every time our team has to find a matching test management platform for a new project, we weigh up the following factors beforehand:

• Application tech stack ― programming languages and frameworks used by the development team. This will define to which testing environment and debugging facility we are restricted.
• Software development methodology followed on the project (Agile, Waterfall, etc.).
• Software testing tools that are currently in use, if any, to know what integrations to look for in a test management platform.
• Project requirements, its scope, and deliverables.
• Project scale ― how large and how long in duration the project is expected to be.
• Project type: web, desktop, or mobile.
• Size of the team to understand if we need a system that supports collaborative use.
• Types of testing required to execute, which lets us find out the ratio of static and dynamic testing tools on the project.
• Quality assurance budget that will define if we use open-source software or go for a ready-made solution.

If you don’t have much experience comparing the different QA management tools, here are a few that we recommend checking out as your starting point for further comparison:

• Zephyr is one of the largest software testing tools that perfectly suits Agile teams and enables continuous quality improvement and bug tracking in real time. Comes in several different editions: for smaller one-time testing projects, large enterprise software products, and the one that seamlessly syncs multiple technical teams together, all well compatible with Jira by Atlassian.

• qTest test case management platform supports numerous integrations like open-source frameworks and automation tools, as well as allows QA teams to use different types of tasks for different types of testing. The flexibility of qTest makes it suitable for various software development methodologies, Waterfall included.

• PractiTest is a QA management multi-tool that offers maximal visualization for all your processes and achievements. While having all the technical features that you would expect to see in a test management system (from task tracking to integrations with Jira, Eggplant, Azure DevOps, Rally, etc.), it makes the working process a lot easier for people preferring the visual learning style.

• TestRail is a great option for teams who value reporting and documentation over anything else in testing. The functionality of this test case management system includes multiple types of automated reporting and a wide range of customizable metrics that you fill in once and just let the program track them with minimal human involvement. It is great for insight-driven testing that is beneficial for both end product quality and operations management.

• Test Collab is an intuitive platform to manage all QA processes from one powerful dashboard. It is well suited for the adopters of early testing approach due to its great test planning functionality. You can customize the dashboard up to your preferences, as well as set all the milestones, product requirements, and long-term project objectives and let the system help you track the achievement of each.

No matter what software testing platform you’re going to choose for your project, banking and finance application testing is impossible to keep productive without one. By maintaining the accurate project planning, linking different experts and teams together, and tracking the progress, a test management system basically becomes an integral part of your QA operations.

Leave room for future growth

They say a good plan makes the job half-done, and we couldn’t agree more, especially in the context of software testing for banking. The BFSI industry highly depends on IT, which creates pressure for software owners to keep up with the emerging tech trends so that their digital products would remain concurrent and interesting in the eyes of consumers. And while there’s no doubt in the importance of continuous digital transformation of banking applications, many product owners do not realize that unless you have planned for software scalability, it’s going to be extremely difficult to transform in the future.

Software scalability is the ability of a system to extend its functionality and capacity when needed. In other words, a scalable application allows software engineers to add new features to the existing codebase instead of starting over the development process only because they need some extra functions on board. Unfortunately, scalability is only achievable if planned early and implemented in the codebase on the architectural level. But how to find out if your banking application is going to be technically scalable? Of course, through early banking app testing.

Involving QA engineers to work on complicated projects like finance software as early as you can always pays back with a better performance and saved resources. Usually, when people think of how to test banking application, they imagine the process to follow as “develop first, test later”. In reality though, if you want to end up with a future-proof digital solution with enough room for new functionality when needed, we strongly recommend adding prototype and requirements testing to your QA scope. By gathering expert opinions about what is planned to be built, you will be able to predict potential bottlenecks on the paper rather than urgently fix them before the release. With such a sensitive sector as finance management, early testing ensures a strong brand reputation and unwavering consumer trust.

“For a banking application to be viable, the first and foremost thing it has to give its users is the confidence about their data safety. Followed by a high performance, intuitive UI/UX, and wide platform and OS coverage, these attributes will make a banking application that needs no alternatives in the eyes of consumers.”

Igor Kovalenko, QA Team Lead

Start looking for a way out from legacy solutions

Financial institutions are generally prone to bureaucracy that oftentimes holds them back from technological advancement. The thing is, in order to keep their internal operations running as safely as possible, banks and insurance entities cannot adopt IT change fast. That’s why the vast majority of modern banks are stuck with legacy operating systems and mainframe technologies that are just too huge and puzzling to transform, which may create additional challenges when you test banking domain applications. Generally, there’s nothing too bad about legacy systems as long as they work as required. But once you stumble across an emergency or just a new technology invented that your bank just can’t ignore, the legacy and mainframe systems might put at risk the functioning (if not the whole existence) of a bank.

A vivid example of such an emergency is the infamous COBOL crisis of 2020. In short, after the pandemic hit the fan, numerous US government departments experienced a huge increase in online unemployment claims. There were so many, that the mainframe system to process them simply could not stand the load. That mainframe system was based on COBOL (Common Business Oriented Language) ― a programming language created and widely used in the 1960s. It is outdated to the point that the majority of COBOL talent pool is now in their 70s, and the state had to ask for help from retired programmers to put the software back on track. It worked this time, luckily, but as the time goes by, next time there might be no such option available.

Is there a solution for finance establishments dependent on their legacy applications? We believe there is, even though the transformation path for such enterprises won’t be the easiest. If you don’t want to realize one day that your operating system is just a pile of fossils, we recommend you to set a solid QA process before the need for change actually comes into play. Again, the earlier software quality experts enter your SDLC, the less inaccuracies will make it to the end product. No digital product will benefit from QA supervision more than a large legacy solution that’s been developed for years. In this case, the duties of the software testing department are shifting to the strategic planning, code analysis, and prototyping from the usual pre-release testing, which is in fact just a small part of what quality assurance teams actually do.

Peculiarities of banking domain testing

What is BFSI domain in testing?

BFSI domain testing is a set of activities executed by software testing engineers to assure a banking application meets the technical requirements and works smoothly. Any operation aimed at achieving the higher software quality or fixing a glitch in a finance-related digital product falls into the BFSI domain testing. This means, the objectives for such an operation have to be aligned with the most important characteristics of a banking application. You may also consider adding a domain expert to your QA team to ensure that the application gets the best possible treatment.