Key Considerations for Testing Financial Apps

Not all applications are alike. Different types of software may require different kinds of design, different methods of implementation, and different types of testing, depending on the market for the application, its function, and its target users. In this post, we'll take a look at some of the things you should keep in mind when laying out a strategy for testing financial software.

Software developed for use within the financial and banking industries often must meet very strict requirements, which arise from the need to handle transaction and customer records with a high level of security, the need to accurately and precisely track the flow of money, and above all, the generally very strict and often overlapping regulatory regimes under which finance and banking must operate.

In testing financial software, it is important to take all of these considerations into account, along with the basic functional requirements of financial and banking software, as well as the fundamental issues which arise in connection with virtually all software testing.

With regard to devising a testing strategy, what are the key characteristics of financial software?

Financial applications and systems which store financial data are among the top targets of the most sophisticated cyber-criminal operations. By gaining access to customer and transaction records, or applications which control the flow of money, criminals may be able to fraudulently withdraw or divert funds, set up phony accounts for money laundering, or alter records to conceal details of transactions. They can in effect rob individual customers or financial institutions with near-perfect anonymity, and virtually no physical risk.

Financial and banking applications must process and store transaction data reliably and accurately, and they must have a very high level of availability. While many of the elements which contribute to this kind of basic reliability are fairly easy (if not trivial) to program and test, the high-stakes nature of financial software requires that they not be taken for granted.

Financial applications are often required to handle a very high volume of transactions, and handle them very rapidly. This is true for customer-oriented software in areas such as consumer banking, online loan processing, and point of sale transactions, and it is also true for many non-consumer applications, such as those that handle trading stocks, commodities, or derivatives. Automated transactions in these areas may occur in very high volume, and may require extraordinary rapidity and precision of timing.

Virtually all financial software must comply with the requirements of one or more regulatory agencies. Very often, an application must adhere to the standards of multiple regulators operating under the authority of different regional or national governments, or various international bodies. Compliance can be a matter of extreme importance—Failure to comply can in some cases result in civil, financial, or even criminal penalties for the organizations or individuals found to be responsible.

The workflows involved in financial and banking software may be extremely complex, and individual applications may be closely integrated with a large number of other programs, all of which may be handling an enormous number of transactions. When you combine this overall complexity with the need for validation, reporting, and auditing, as well as the real-time nature of many of the interactions, the actual level of complexity is even greater.

What, then, are the best testing strategies for financial software?

As is always the case, your testing regime must cover basic functionality and performance. This includes both the very obvious functional issues (user interface, input, output, and storage), and those features which by all rights should not be a problem, given the basic nature of the software.

This last group includes such things as computational accuracy. You cannot assume that simply because you are testing a revision of an existing financial application, you do not need to check the math. A change to the code in one part of a program can have an unanticipated effect on something as simple and as seemingly unrelated as the arithmetic calculations in another part of the program.

In the case of financial software, the cost of such a bug (and of missing it during testing) can be extremely high. The same is true of such obvious beginner's errors as unmanaged buffer overflows. It never pays to neglect the basics.

You should create a set of general business scenarios (and their associated test cases) based on the requirements of the software. In the case of financial and banking software, it is important to work closely with analysts and other professionals on the client side (the institutions which will be using the software) to make sure that these scenarios accurately and fully reflect the ways in which the software will be used.

Use cases are always important. For financial software, the key use cases would be those which reflect:

Beyond basic performance testing, financial applications should be tested for operation under heavy loads, and conditions which place a high degree of stress on both the software and on its infrastructure.

Note that load testing and stress testing are not the same. Load testing looks at the way that the application handles a very large volume of transactions and associated operations, such as database reads and writes.

Stress testing, on the other hand, is focused more on the way that the application handles a high volume of transactions over a prolonged period of time. It can pick up cumulative problems, such as memory creep, which might not be apparent under simple load testing.

In the case of financial and banking software, the safest assumption is that it will routinely run under both heavy load and high-stress conditions.

Needless to say, testing for security problems is crucial. You must assume that the application you are testing will be under constant attack by professional criminals, who will attempt to exploit any vulnerability they find, at a potentially extremely high cost to the application's users.

You cannot assume that adequate security is already built into the software. It is better (and in many ways more realistic) to assume that the software contains undetected vulnerabilities, and that it is your job to find them.

Given the number of high-profile data breaches reported in the news, it is clear that adequate programming and testing for security are not always the rule. The security tests you perform may be crucial to the privacy, financial security and retention of your business clients.

There are a variety of other things which you should test for as well, including disaster recovery, response time, reporting, logging, and auditing. But the areas of testing which we have listed here are in general the most important, and cover the key functional, performance, and vulnerability issues with regard to financial software.

As is always the case, the breadth, depth, and scope of testing are crucial. Highly automated parallel testing will typically give you the best and broadest in-depth coverage, particularly for load, stress, and security testing.

Testing financial software does require a well thought-out strategy, but with the right testing tools and infrastructure, it can be a lifesaver for both you and your clients.

Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues. He is a regular Fixate.io contributor.