A financial application is a software program that facilitates the management of business processes that deal with money. It is a type of software that is specifically designed to automate, assist and store financial information of a personal or business nature. It handles the storage, analysis, management and processing of a set of financial transactions, records and processes
Financial software is built on the principles of financial information management. It may be executed as standalone software or as part of a financial information system (IS). Most financial software incorporates all facets of personal or business finance and provides numerous features, including Basic financial data management, financial transactions and management, Budgeting, Account management, and financial assets management.
Some of the characteristics of a Typical Financial application are Multi-tier functionality to support thousands of concurrent user sessions, large scale Integration, typically a banking application integrates with numerous other applications such as Bill Pay utility and trading accounts and complex business workflows. They also involve Real Time and Batch Processing with high rate of transactions per second. The transaction processor which could be a large capacity mainframe or any other legacy system to carry out trillions of transactions per second. This makes financial applications so complex.
Typical stages involved in testing the applications is illustrated below,
Testing banking and financial applications require an end to end testing methodology involving multiple software testing techniques to ensure:
- Total coverage of all banking workflows and business requirements
- Functional aspect of the application
- Security aspect of the application
- Data Integrity
- User Experience
- Performance of the application
There are a few aspects that need be well considered when testing financial applications. The top 5 aspects are as below,
Involvement of Business from early stages
Right from the very beginning of the project, the testing team must collaborate with the business stake holders and the business analysts to understand the business requirement of the application. Requirements are gathered as per customer needs and documented by financial experts or business analysts. To write requirements on more than one subject matter experts are involved as the application might be involving integration of different domains or the application might contain multiple lines of business in a single domain. For Example: A banking application may have separate modules for transfers, credit Cards, reports, loan accounts, bill payments, trading Etc.
The deliverable of requirement gathering is reviewed by all the stakeholders such as QA Engineers, Development leads and Peer Business Analysts. They cross check that neither existing business workflows nor new workflows are violated. The Business Scenarios are derived in such a way that all Business Requirements are covered. Business Scenarios are high level scenarios without any detailed steps, further these Business Scenarios are reviewed by Business Analyst to ensure all of Business Requirements are met and it’s easier for BAs to review high level scenarios than reviewing low level detailed Test Cases.
Understanding the Domain and the Application
A financial application may be interacting with or a part of different domain applications. It is necessary that the tester is equipped with adequate knowledge of the domain that is being involved.
Are we going to test the BFSI applications (Banking, Financial Services and Insurance) just for UI or functionality or security or load or stress? No. We should know what the user requirements in banking are, working procedures, commerce background, and exposure to brokerage etc and should test application accordingly, then only we can say that our testing is enough. When we know the functional domain better we can better write and execute more test cases and can effectively simulate the end user actions which are distinctly a big advantage.
For example, in the below illustration, it is shown, how the financial applications can be integrated with the different domain applications.
Impact analysis is basically analyzing the impact of the changes in the deployed application or product. It tells us about the parts of the system that may be unintentionally got affected because of the change in the application and therefore need careful regression testing. This decision is taken together with the stakeholders.
QA team has to find out the areas which may get impacted because of the defect fixes; this is called as impact analysis. Depending on this impact analysis, few more test cases are pulled to look after the impacted areas of the software. The technique or method is known as selective re-testing because testing technique concentrates on reuse of pre-existing test cases which is already executed.
Functional Testing – White box Testing
White box testing is essential for testing financial applications. Testing a system with full knowledge and access to all source code and architecture documents can reveal bugs and vulnerabilities more quickly. In this stage functional testing is performed and the usual software testing activities are performed such as: Test Case Preparation, Test Case Review and Test Case execution. The functional testing also includes the following services:
- Application testing
- System integration testing
- Regression testing
- User Acceptance Testing
Application Security and Performance
Security Testing is usually the last stage in the testing cycle as completing functional and non-functional are entry criteria to commence Security testing. Each day financial institutions trade millions of dollars’ worth of cash or commodities. A single security breach can result in severe long-term damage to a firm’s financial stability and customer trust. Integration with the third-party applications, constantly emerging customer base, proliferation of Internet, complex business workflows, growing remote and mobile workforce makes these applications and the data that they host, vulnerable to threats from a myriad number of sources. Protection of data from these threats and malicious attacks is imperative to avoid loss of reputation and financial loss. With number of security products growing up, there is still lack of attention in resolving security issues in online banking systems, payment gateways, insurance covers etc. and need to be resolved.
Security Testing can make your applications more secure by identifying and addressing security vulnerabilities. It is one of the major stages in the entire Application Testing cycle, as this stage ensures that application complies with Federal and Industry standards. It makes sure the application does not have any web vulnerability which may expose sensitive data to an intruder or an attacker and complies with standards like OWASP (The Open Web Application Security Project).
Today’s financial services institutions are continuously expanding into new markets and products, often increasing the load on IT systems and driving a need for performance engineering across the testing lifecycle. Performance Engineering can help predict, test and manage loads on your most critical systems to ensure performance, scalability and reliability. The Financial institutions need to adapt to increasingly fast-paced applications development cycles, and increasingly complex applications, without compromising application quality. The benefits of Performance Engineering are as below
- Constant Monitoring and reporting activities.
- Increased productivity.
- Reduced defect costs.
- Reduced down-time leading to improved customer satisfaction.
In summary, we can improve the efficiency of the financial applications with proactive testing and risk management. Testing financial applications is more interesting but it’s a massive system and the testing processes need to be strictly followed to ensure a quality product and satisfied customers.
Latest posts by Vijay Anandan (see all)
- Top 5 Aspects to consider when testing financial applications - April 18, 2015