{"id":243,"date":"2019-11-18T03:53:42","date_gmt":"2019-11-17T22:23:42","guid":{"rendered":"https:\/\/coforge.site\/cigniti\/blog\/?p=243"},"modified":"2022-07-28T20:20:15","modified_gmt":"2022-07-28T14:50:15","slug":"testing-online-banking-applications-hypothesis","status":"publish","type":"post","link":"https:\/\/coforge.site\/cigniti\/blog\/testing-online-banking-applications-hypothesis\/","title":{"rendered":"Testing online Banking applications: A hypothesis"},"content":{"rendered":"

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.<\/span>\u00a0<\/span><\/p>\n

How is that related to banking? To answer this question<\/span>,<\/span>\u00a0let\u2019s look at an example<\/span>:<\/span>\u00a0<\/span><\/p>\n

W<\/span>hen a customer performs an action on\u00a0<\/span>an<\/span>\u00a0online banking application<\/span>,<\/span>\u00a0the information generated travels back and forth through numerous complex systems\u00a0<\/span>to ensure<\/span>\u00a0data integrity, security<\/span>,<\/span>\u00a0and swift transaction completion time. If th<\/span>is<\/span>\u00a0was not enough<\/span>,<\/span>\u00a0the systems also need to ensure that they are up-to-date with regulatory compliance governed by banking bodies<\/span>\u00a0and\u00a0<\/span>Federal Laws. For the end user<\/span>, all they do is make a click. B<\/span>ut, in reality<\/span>,<\/span>\u00a0it<\/span>\u00a0i<\/span>s a deep dive!<\/span>\u00a0<\/span><\/p>\n

Even a simple flow may involve many checks<\/span><\/b>\u00a0<\/span><\/p>\n

\"Testing<\/p>\n

Drilling through the Iceberg<\/span><\/b>\u00a0<\/span><\/p>\n

Banking systems are an intertwined ball of interfaces which crossfire (<\/span>and possibly<\/span><\/i>\u00a0<\/span><\/i>m<\/span><\/i>isfire<\/span><\/i>) in all directions. We are talking about real<\/span>–<\/span>time interfaces which require multiple requests and responses within seconds to ensure<\/span>\u00a0total<\/span>\u00a0sync.\u00a0<\/span>It is similar to the<\/span>\u00a0voluminous traffic conditions which go hay-wired at multiple\u00a0<\/span>road\u00a0<\/span>intersections\u00a0<\/span>while<\/span>\u00a0you try to\u00a0<\/span>make your way<\/span>\u00a0out. With such a huge data flow<\/span>, it gets challenging to<\/span>\u00a0maint<\/span>ain<\/span>\u00a0optimum performance with effective and realistic response times. When\u00a0<\/span>these systems grow enormous and when we expect them to function with a certain degree of accuracy, Software Testing<\/span>\u00a0becomes an important determinant<\/span>. There may be different school of thoughts on \u201cHow to test?\u201d 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<\/span>,<\/span>\u00a0time<\/span>,<\/span>\u00a0and effort<\/span>,<\/span>\u00a0which not only leads to errors in data integrity but also traumatizing embarrassment. Banking systems span across sub-domains such as\u202f<\/span>Investment Banking, Retail Banking<\/span>,<\/span>\u202f<\/span>and<\/span>\u202fCommercial Banking<\/span>.\u202f<\/span><\/i>Each sub<\/span>–<\/span>banking system has its own set of testing needs\u00a0<\/span>that<\/span>\u00a0<\/span>has<\/span>\u00a0to be addressed for the desired outcome.<\/span>\u00a0<\/span><\/p>\n

The Speed Breakers<\/span><\/b>\u00a0<\/span><\/p>\n

Data Volume<\/span><\/b>:\u00a0<\/span><\/b>Banking systems indiscriminately rely on huge\u00a0<\/span>volumes<\/span>\u00a0of data<\/span>. E<\/span>ven a small operation generates a lot of\u00a0<\/span>information.<\/span>\u00a0For instance, a simple event such as Log-in to the system may capture Log-in Date, Log-in Time, Location of the<\/span>\u00a0<\/span>User,<\/span>\u00a0and<\/span>\u00a0Audit Trail<\/span>\u00a0–\u00a0<\/span>a<\/span><\/i>ll this when the user did<\/span><\/i>\u00a0no<\/span><\/i>t even perform any real action<\/span><\/i>. Within complicated systems data may eventually be stored in the application databases or cloud<\/span>–<\/span>based database<\/span>s,<\/span>\u00a0thousands of miles away. Data storage and retrieval pose a\u00a0<\/span>severe<\/span>\u00a0challenge<\/span>\u00a0for banking organizations.<\/span>\u00a0<\/span><\/p>\n

Approach towards handling large Data Volume Tests<\/span><\/b>:<\/span><\/b>\u00a0The approach from the test management perspective<\/span>\u00a0recommends<\/span>\u00a0creat<\/span>ion of<\/span>\u00a0distinct data sets per interface,\u00a0<\/span>i<\/span>ron<\/span>ing<\/span>\u00a0out key areas of impact for a particular feature across interfaces<\/span>,<\/span>\u00a0and plan<\/span>ning<\/span>\u00a0tests accordingly.\u00a0<\/span>\u00a0<\/span><\/p>\n

Different banking projects have different test data needs. For instance<\/span>,<\/span>\u00a0a retail banking project may require lots of test data related to user accounts,\u00a0<\/span>funds transfe<\/span>r and\u00a0<\/span>mobile deposits<\/span>. An investment banking projects may need test data related to\u00a0<\/span>derivatives<\/span>, bonds, stocks<\/span>,<\/span>\u00a0etc. These factors need to be carefully\u00a0analysed\u00a0and test data sets should be created accordingly (per environment). Any updates to these should be versioned\/tracked.<\/span>\u00a0<\/span><\/p>\n

Two key areas that needs to be introduced selectively are Functional automation and\u202f<\/span><\/span>Performance Testing<\/span><\/span><\/a>. Functional automation helps because manually validating everything can be a time<\/span><\/span>–<\/span><\/span>consuming activity if tests need to<\/span><\/span>\u00a0be<\/span><\/span>\u00a0run over and over again. Automation can be significant when business needs require Exhaustive testing (<\/span><\/span>testing\u00a0<\/span><\/span>all the possible combinations), which is otherwise not possible with manual execution methodologies. Not only does it improve accuracy of the\u00a0<\/span><\/span>tests,<\/span><\/span>\u00a0but the testing team can focus on other activities which may help\u00a0<\/span><\/span>improve\u00a0<\/span><\/span>the overall product<\/span><\/span>\u00a0quality<\/span><\/span>. 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\u00a0<\/span><\/span>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.<\/span><\/span>\u00a0<\/span><\/p>\n

Legacy Systems<\/span><\/b>:<\/span><\/b>\u00a0<\/span>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.<\/span>\u00a0Almost half of bankers perceive legacy systems to be the biggest barriers to the growth of the commercial<\/span>\u00a0<\/span>banks, as per the recent research by\u00a0Fraedom. 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.<\/span>\u00a0<\/span><\/p>\n

Approach towards handling Legacy System Tests<\/span><\/b>:<\/span><\/b>\u00a0A\u00a0<\/span>dedicated\u00a0<\/span>and specialist team is required to handle legacy systems<\/span>\u00a0as\u00a0<\/span>people with real experience managing a systematic test approach may come in handy here. Another\u00a0<\/span>practical<\/span>\u00a0approach would be to incorporate all the business<\/span>-c<\/span>ritical functional tests per environment (QA, UAT, Staging etc.). Ensuring prompt tests on all the environments will<\/span>,<\/span>\u00a0to a certain degree<\/span>,<\/span>\u00a0ensure a better performance and catch a particular bug on time<\/span>,<\/span>\u00a0especially on the staging environment. These tests need to be closely monitored and administered though.<\/span>\u00a0<\/span><\/p>\n

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

Interfacing Systems<\/span><\/b>:<\/span>\u00a0Banking 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\u00a0<\/span>whether or not<\/span>\u00a0you were involved in fraudulent practices earlier. What if your account was hacked and someone tried logging into your account from Costa<\/span>\u00a0<\/span>Rica? There are interfacing systems which ensure checks on all the inferences made above and react in milliseconds! Within no time<\/span>,<\/span>\u00a0all the information is sourced into the central system for further action and decision making.<\/span>\u00a0<\/span><\/p>\n

Approach towards handling interfacing system tests<\/span><\/span>:<\/span><\/span><\/strong>\u00a0This proves out to be the tricky section and the entire\u202f<\/span><\/span>banking application testing<\/span><\/span><\/a>\u202fneeds depends on this section and how we streamline it. The most important approach in testing the interfacing systems are end<\/span><\/span>–<\/span><\/span>to<\/span><\/span>–<\/span><\/span>end tests. Typically<\/span><\/span>,<\/span><\/span>\u00a0software testing teams tend to write separate test scenarios for different pieces. If tests are written interface<\/span><\/span>–<\/span><\/span>wise<\/span><\/span>,<\/span><\/span>\u00a0one after the other<\/span><\/span>,<\/span><\/span>\u00a0from the beginning of the transaction to the end<\/span><\/span>,<\/span><\/span>\u00a0it will ensure test\u00a0<\/span><\/span>completion resulting in a more holistic testing approach. Adding priorities to each interfacing test may lead to better test completion<\/span><\/span>,<\/span><\/span>\u00a0especially if the test team is running against schedule\/time.<\/span><\/span>\u00a0<\/span><\/p>\n

Device\u202fCompatibility<\/span><\/b>:<\/span>\u00a0<\/span>No one really visits a bank\u00a0any more<\/span>? We\u00a0<\/span>demand<\/span><\/i>\u00a0access 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) \u2013\u00a0<\/span>No concessions whatsoever<\/span><\/i>! Device Fragmentation proves out to be a major bottleneck in providing secure and an effective user experience. Different devices behave differently<\/span>,<\/span>\u00a0resulting 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.<\/span>\u00a0<\/span><\/p>\n

Approach towards handling compatibility tests<\/span><\/b>:<\/span>\u00a0With such huge fragmentation it gets difficult to perform exhaustive testing (period). However<\/span>,<\/span>\u00a0what could be done is carefully understand the customers of the product and the area in which the product usage is rampant. Once\u00a0<\/span>this information is<\/span>\u00a0derive<\/span>d,<\/span>\u00a0we can get an online split on what are the most widely<\/span>–<\/span>used platform based on\u00a0<\/span>the\u00a0<\/span>socioeconomic factors. On the other hand<\/span>,<\/span>\u00a0if the application is already in operation and people are using it extensively<\/span>,<\/span>\u00a0we 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<\/span>,<\/span>\u00a0in USA and Canada the focus may be on High<\/span>–<\/span>end IOS\/Android phones while Brazil would need the application to be tested on low<\/span>–<\/span>end Android phones. Marketing team and the product solutions may provide insightful statistics to iron out the most effective tests.<\/span>\u00a0<\/span><\/p>\n

Team Fragmentation<\/span><\/b>:<\/span>\u00a0The world is a global village with respect to technologies. These days,\u00a0<\/span>development\u00a0<\/span>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\u00a0<\/span>reality,<\/span>\u00a0it 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\u00a0times take a hit).<\/span>\u00a0<\/span><\/p>\n

Approach towards handling spread out teams<\/span><\/b>\u202f<\/span><\/i><\/b>\u2013 There are a few major areas that can be pivotal in a successful QA project delivery with teams sitting across locations.<\/span>\u00a0<\/span><\/p>\n