Testing online Banking applications: A hypothesis

Icebergs can be deceptive when looked at! They encompass a huge mass below the sea level which is around 90% of its actual size, leaving only 10% for the naked eye. 

How is that related to banking? To answer this question, let’s look at an example: 

When a customer performs an action on an online banking application, the information generated travels back and forth through numerous complex systems to ensure data integrity, security, and swift transaction completion time. If this was not enough, the systems also need to ensure that they are up-to-date with regulatory compliance governed by banking bodies and Federal Laws. For the end user, all they do is make a click. But, in reality, it is a deep dive! 

Even a simple flow may involve many checks 

Drilling through the Iceberg 

Banking systems are an intertwined ball of interfaces which crossfire (and possibly misfire) in all directions. We are talking about real–time interfaces which require multiple requests and responses within seconds to ensure total sync. It is similar to the voluminous traffic conditions which go hay-wired at multiple road intersections while you try to make your way out. With such a huge data flow, it gets challenging to maintain optimum performance with effective and realistic response times. When these systems grow enormous and when we expect them to function with a certain degree of accuracy, Software Testing becomes an important determinant. There may be different school of thoughts on “How to test?” but Testing certainly plays a key role in optimizing the symphonic sync between systems. Studies have shown that fixing banking defects in production have cost a lot of money, time, and effort, which not only leads to errors in data integrity but also traumatizing embarrassment. Banking systems span across sub-domains such as Investment Banking, Retail Banking, and Commercial Banking. Each sub–banking system has its own set of testing needs that has to be addressed for the desired outcome. 

The Speed Breakers 

Data Volume: Banking systems indiscriminately rely on huge volumes of data. Even a small operation generates a lot of information. For instance, a simple event such as Log-in to the system may capture Log-in Date, Log-in Time, Location of the User, and Audit Trail – all this when the user did not even perform any real action. Within complicated systems data may eventually be stored in the application databases or cloud–based databases, thousands of miles away. Data storage and retrieval pose a severe challenge for banking organizations. 

Approach towards handling large Data Volume Tests: The approach from the test management perspective recommends creation of distinct data sets per interface, ironing out key areas of impact for a particular feature across interfaces, and planning tests accordingly.  

Different banking projects have different test data needs. For instance, a retail banking project may require lots of test data related to user accounts, funds transfer and mobile deposits. An investment banking projects may need test data related to derivatives, bonds, stocks, etc. These factors need to be carefully analysed and test data sets should be created accordingly (per environment). Any updates to these should be versioned/tracked. 

Two key areas that needs to be introduced selectively are Functional automation and Performance Testing. Functional automation helps because manually validating everything can be a time–consuming activity if tests need to be run over and over again. Automation can be significant when business needs require Exhaustive testing (testing all the possible combinations), which is otherwise not possible with manual execution methodologies. Not only does it improve accuracy of the tests, but the testing team can focus on other activities which may help improve the overall product quality. Performance testing on the other hand should ideally be performed in various stages of the product lifecycle. A few performance related tests should be performed during the development phase and a few post the testing cycle is over just before going live. Since banking systems thrive on transactional data predominantly, careful planning of test data and its strategy could result in significant gains. 

Legacy Systems: Legacy systems can be a real threat when it comes to consistency. Testing gets tricky with these old systems. Challenge quadruples as these systems usually have minimal or no documentation for troubleshooting. Almost half of bankers perceive legacy systems to be the biggest barriers to the growth of the commercial banks, as per the recent research by Fraedom. The numerous outages across the top high street banks are forcing or have forced the banks to move on to more advanced solutions and probably adopt FinTech. 

Approach towards handling Legacy System Tests: A dedicated and specialist team is required to handle legacy systems as people with real experience managing a systematic test approach may come in handy here. Another practical approach would be to incorporate all the business-critical functional tests per environment (QA, UAT, Staging etc.). Ensuring prompt tests on all the environments will, to a certain degree, ensure a better performance and catch a particular bug on time, especially on the staging environment. These tests need to be closely monitored and administered though. 

Creation of user guides with screenshots also impacts the overall testing. Functional guides /knowledge repository can be gold mine here. It is strongly advised that the QA Manager plan creation of up-to-date user guide with screenshots (videos score brownie points here). Guides help in pin–pointing issues and new testers/developers can have access to a functional repository of the legacy system. 

Interfacing Systems: Banking systems these days are tight bundle of a myriad of systems. Banks may be interested in knowing your credit score, they may also want to see whether or not you were involved in fraudulent practices earlier. What if your account was hacked and someone tried logging into your account from Costa Rica? There are interfacing systems which ensure checks on all the inferences made above and react in milliseconds! Within no time, all the information is sourced into the central system for further action and decision making. 

Approach towards handling interfacing system tests: This proves out to be the tricky section and the entire banking application testing needs depends on this section and how we streamline it. The most important approach in testing the interfacing systems are end–to–end tests. Typically, software testing teams tend to write separate test scenarios for different pieces. If tests are written interface–wise, one after the other, from the beginning of the transaction to the end, it will ensure test completion resulting in a more holistic testing approach. Adding priorities to each interfacing test may lead to better test completion, especially if the test team is running against schedule/time. 

Device Compatibility: No one really visits a bank any more? We demand access to all the banking services while on the move and expect the mobile banking application to work on all the devices across platforms (Desktops / Tabs / Mobile Devices) – No concessions whatsoever! Device Fragmentation proves out to be a major bottleneck in providing secure and an effective user experience. Different devices behave differently, resulting in the same banking app yielding a different result. This chaotic situation poses a distinct challenge of testing the same features for functional and UX consistencies. Device compatibility directly impacts the user experience and can be a decisive factor in evaluating failure or success of a product. 

Approach towards handling compatibility tests: With such huge fragmentation it gets difficult to perform exhaustive testing (period). However, what could be done is carefully understand the customers of the product and the area in which the product usage is rampant. Once this information is derived, we can get an online split on what are the most widely–used platform based on the socioeconomic factors. On the other hand, if the application is already in operation and people are using it extensively, we can get the list of devices from paid data providers. This is by far the most accurate way to narrow down the tastes and preferences of consumers as far as device fragmentation goes! It also helps in judging the acceptability of radical solutions being served. For instance, in USA and Canada the focus may be on High–end IOS/Android phones while Brazil would need the application to be tested on low–end Android phones. Marketing team and the product solutions may provide insightful statistics to iron out the most effective tests. 

Team Fragmentation: The world is a global village with respect to technologies. These days, development and testing teams sit at different locations due to various reasons pertaining to costs and availability of technology. While development teams get away easily as they are just worried about modular development, testing teams come under real pressure with this paradigm. Testers need to know how the application flow works, test the application, log defects, find requirement flaws and most importantly do all of this within a tight and a strict timeline. Most of you who read this may feel Team fragmentation does not make a huge difference, but in reality, it is always easy to deliver projects where teams are co-located on the other hand banking projects talk to so many interfaces that it gets difficult for all the teams to be co-located. It gets worse if the teams are located in different time-zones (Turn around times take a hit). 

Approach towards handling spread out teams – There are a few major areas that can be pivotal in a successful QA project delivery with teams sitting across locations. 

• Environment – The QA Environment needs to be in ship shape and fully loaded. With remote teams accessing the system it always helps to have lightning fast responses. The approvals and information infringement agreements should be taken care of well in advance with VPN setup and tested. The mobile testing facility should be given utmost important as with remote testing setups testing mobile apps is a challenge. 
• One tool Approach – QA Team / Product Team and The Dev team should be on a single project management tool so that the information is not repetitive and most importantly not lost! Choosing a simple tool helps here, complicated tools are feature rich but are difficult to use. Logging defects, Test case management and in fact any project approval should be done within the tool, possibly in the form of comments; instead of sending boring emails. All the major stakeholders from all the interfaces should have access to the tool and they should be using it for most of the communication. Communicating on time is critical for a successful QA Delivery. 
• Effective defect triage meetings – When banking applications are tested, a bug raised on front–end could actually be a back-end issue. Defects can be misleading! Instead of beating around the bush or assigning them to wrong people (which gobbles up precious time), it may be worthwhile pulling all the key people involved into frequent defect triage meets. Based on the project timelines, an effective triage plan should be laid out. QA Team should be driving this meeting and each meeting should be preceded by a meaningful agenda and exact areas to be discussed, be it Defects or Requirements. Once the team gets used to the triage meets over a period of time it improves defect to remark ratio and betters defect severity index. 

Environment Stack: Banking applications are critical in nature and with real money involved the stakes are pretty high. Banking application typically have QA, UAT, Staging, and Production environments. With the increase in environments the complexities grow equally. Once in production any release needs to perform optimally across environments both functionality and performance wise. 

Approach towards handling environment: It may sound and appear insignificant, but the environment management team plays a crucial role across all the phases of the application development, Testing, and Release. Environment management needs to be a full-time job and the efforts should not be shared by IT/Development and QA Team, especially when it comes to banking projects. Builds need to be managed effectively and tracked with proper release notes. The environment management team and QA Team should be working in–sync. The QA Manager should be approving any change that may be applied to the test environment. There should be a published high–level environment management plan with all the major stakeholders of the project, and everyone should abide by the plan (aka Bible). The build frequency should be controlled and consistent with release notes that should contain heads up for the QA and Business teams. There should be a build rollback plan in the event of an un-test worthy build (due to a showstopper bug or error in deployment). Pre–deployment and Post–Deployment note should be sent out to the entire team and a log should be maintained by the environment manager. 

Another critical aspect is the build versioning that needs special attention. I would prefer A.B.C kind of a versioning. A simple but an effective versioning nomenclature. 

A – Major release 

B – Minor release 

C – Build number 

(Build versioning should be clearly highlighted when the testing team opens the application, can be on the Title bar/Homepage/Footer etc. This helps testing defects against relevant application versions.) 

Within banking applications external environments needs to be managed. There may be one external QA Environment and many internal environments that may be consuming the same external QA service, resulting in reconciliation issues in the core banking application. This may pose a critical threat to the overall test results validation. Meetings with the external vendors need to be conducted to eliminate these issues much earlier before the actual sprinting phase begins. 

These basic checks can ensure a smooth sail of the environment from a testing perspective of a banking application. 

Final Thoughts 

In many ways, testing banking applications can be a complicated deal, but in the grand scheme of things if all the aspects of the project are dealt with proper care and planning, many pitfalls may be averted. If the key methods and principles are in place right from the word go, it can be beneficial and can have real long–lasting advantages. Hiccups will be there (Even NASA has em!) and there is no getting away. It’s the way we take decisions and how we mitigate the risks/issues makes the real difference. The right blend of people and processes are key ingredients of a successful testing implementation of a Banking Application Suite.