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 the online banking application the information generated travels back and forth through numerous complex systems ensuing data integrity , security and swift transaction completion times. If that was not enough the systems also need to ensure that they are up-to-date with regulatory compliance governed by banking bodies/Federal Laws. For the end user it’s just a click but, in reality it’s 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 (Read Misfire) in all directions. We are talking about real time interfaces which require multiple requests and responses within seconds to ensure sync. Imagine voluminous traffic conditions which go hay-wired at multiple intersections and you try to sneak out. With such a huge data flow the maintenance of optimum performance with effective and realistic response times gets challenging. When these systems grow enormous and when we expect them to function with a certain degree of accuracy, one important factor in determining all of that is Software Testing. There may be different school of thoughts on “How to test?” but Testing certainly plays a key role in optimising 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 traumatising embarrassment. Banking systems span across sub-domains such as Investment Banking, Retail Banking and Commercial Banking etc. Each sub banking system has its own set of testing needs which need to be addressed and tweaked for the desired outcome.
The Speed Breakers
Data Volume – Banking systems indiscriminately rely on huge amount of data, even a small operation generates a lot of volume. For instance, a simple event such as Log-in to the system may capture Log-in Date, Log-in Time, Location of the User, Audit Trail etc. All this when the user didn’t even perform any real action. Within complicated systems data may eventually be stored in the application data bases or cloud based database thousands of miles away. Data storage and retrieval pose a strict challenge.
Approach towards handling large Data Volume Tests – The approach from the test management perspective, is to create distinct data sets per interface, iron out key areas of impact for a particular feature across interfaces and plan 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 accordingly.
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 re-run over and over again. Automation can be significant when business needs requires Exhaustive testing (Testing all the possible combinations), which is otherwise not possible with manual execution methodologies. Not only does it improves accuracy of the tests but the testing team can focus on other activities which may help the overall product. 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 – In 2012 RBS customers were unable to access their account due to a glitch in their legacy banking software. CA7 Batch Scheduler crashed leaving 12 Million customer accounts frozen. The bank had to manually update all the account balances. In December 2013 on one of the busiest shopping day’s credit and debit card payments of a major bank went bust. 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.
Approach towards handling Legacy System Tests – A Dedicated and a specialist team is required to handle legacy systems, people with real experience managing a systematic test approach may come in handy here. Another handy 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 if 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.
Heard about Mobile Deposit? The customer can deposit scanned image of a cheques sitting at home and gets a message on the mobile device and an email acknowledging the mobile deposit. All of this is possible only because of smart interfacing systems. This is a complete paradigm shift, from the days when banking only used be confined to the core banking system involved. This shift demands testing to be more versatile and expressive.
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 – Do you like visiting a bank? Honestly we don’t! We want 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. According to a report published by Open Signal as of August 2014 there are 18000+ Distinct Android devices available in the market. Yeah, that’s a lot of devices! Different devices behave differently resulting in the same banking app yielding a different result. This chaotic situation poses a distinct testing 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 you derive this information we can get an online split on what are the most widely used platform based on 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 a 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 respects 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 go through QA à UATà Production and needs to perform optimally across environments both functionally and from the perspective of performance.
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). Be it an Agile or a Waterfall methodology 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 / 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 as well as 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 QA testing 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.
About The Author
Niranjan Keshavan is a Project Lead of QA Delivery at Cigniti Technologies. If you would like to learn more there is a recording of the webinar on how Cigniti can help you assure software quality and succeed in the digital age to provide world class experience to Mobile Banking customers.
Cigniti Technologies is a Global Leaders in Independent Software Testing (IST) Services, is headquartered at Hyderabad, India. Cigniti’s over 1800 people team is spread across US, UK, India, Australia, and Canada. Cigniti is the world’s first IST Services Company to be appraised at CMMI-SVC v1.3, Maturity Level 5, and is also an ISO 9001:2008 & ISO 27001:2013 certified organization.
