(http://www.cigniti.

com/blog/)

24
Shares

22

19 Testing Online Banking Applications: A Hypothesis

1
Jan
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 lets 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 its just a click but, in reality its a deep dive!

Even a simple ow may involve many checks

Drilling through the Iceberg

Banking systems are an intertwined ball of interfaces which cross re (Read Misre) in all directions. We are talking about real time interfaces which require
multiple requests and responses within seconds to ensure sync. Imagine voluminous tra c conditions which go hay-wired at multiple intersections and you
try to sneak out. With such a huge data ow the maintenance of optimum performance with e ective 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 di erent 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 xing banking defects in production have cost a lot of money time and e ort 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 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 didnt 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. Di erent banking projects have di erent 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
(http://www.cigniti.com/blog/)
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 (http://www.cigniti.com/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 signi cant 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 signi cant gains.

24 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
Shares
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
days 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
22 these old systems. Challenge quadruples as these systems usually have minimal or no documentation for troubleshooting.

1
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 con ned 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
(http://www.cigniti.com/mobile-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 di erent 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.

DeviceCompatibility Do you like visiting a bank? Honestly we dont! 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 e ective 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, thats a lot of devices! Di erent devices behave di erently resulting in the same
banking app yielding a di erent 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 di cult 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 e ective tests.

Related: Top 10 Mobile Testing Problems and How to Avoid Them

(http://www.cigniti.com/blog/top-10-mobile-testing-problems-and-how-to-avoid-them/)
 Team Fragmentation The world is a global village with respects to technologies. These days, Development and testing teams sit at di erent 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 ow works, test the application, log
(http://www.cigniti.com/blog/)
defects, nd requirement aws 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 di erence, 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 di cult for all the teams to be co-located. It gets worse if the teams are located in di erent 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 (http://www.cigniti.com/mobile-
24 testing/) is a challenge.
Shares
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 di cult to use. Logging defects,
22 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.
1 Communicating on time is critical for a successful QA Delivery.
Eective 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 e ective 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 optimallyacross environments both functionally and from the perspective of performance.

Approach towards handling environment It may sound and appear insigni cant 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 e orts should not be shared
by IT /Development and QA Team especially when it comes to banking projects. Builds need to be managed e ectively 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.Ckind of a versioning. A simple but an e ective 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 atesting 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, manypitfalls may be averted. If the keymethods and principles are in placeright from the word go,it can be bene cial and can have real
long lasting advantages. Hiccups will be there (Even NASA has em!) and there is no getting away. Its the way we take decisions and how we mitigate the risks
 / issues makes the real di erence. The right blend of people and processes are key ingredients of a successful testing implementation of a Banking
Application Suite.
(http://www.cigniti.com/blog/)
Register for an informative and thought provoking webinar on Jan 21, 12:00 PM EST (http://www.cigniti.com/webinars) to learn how Cigniti & Experitest can
help you assure software quality and succeed in the digital age to provide world class experience to Mobile Banking customers.
By | Niranjan Keshavan

Project Lead QA Delivery at Cigniti Technologies (http://www.cigniti.com/)

Niranjan Keshavan (http://www.cigniti.com/blog/author/niranjan/)

Niranjan is a Retail Banking and Digital Banking expert with around 8.5 years experience. He has been instrumental in managing
delivery functions for various client engagements focused around Digital Banking Transformations. He has experience of working
with cross-cultural teams across varied geo-locations in latest cutting edge technologies.

24
Shares (https://www.linkedin.com/in/niranjan-keshavan-13499a28)

22

1 Comment (1)

Harleen Quinzel (http://www.combank.net) Reply

Hey!Thanks for this information.I am doing a project on internet banking-Commercial Bank.This informatiom will help me a lot

February 14, 2017 at 6:32 PM

Leave a Reply

Your email address will not be published. Required elds are marked *

Comment

Name *

Email *

Website

Post Comment

RELATED POSTS

(http://www.cigniti.com/blog/)

(http://www.cigniti.com/blog/7-complexities-involved-mobile- (http://www.cigniti.com/blog/5-tips-maximize-roi-mobile-test- (http://www.cigniti.com/blog/disruptive-th

testing-need-know/) automation/)
26 19 16 A Disruptive thought Pro
7 Complexities Involved in Mobile Mar
5 Tips To Maximize ROI Of Your Apr Modular Smartphone by
Aug

24
Testing You Need To Know About Mobile Test Automation
(http://www.cigniti.com/blog/7-
Shares (http://www.cigniti.com/blog/5-tips- (http://www.cigniti.com/blog/
complexities-involved-mobile-testing-need- maximize-roi-mobile-test-automation/) thought-project-ara/)
22

About Us

Cigniti Technologies Limited (BSE: 534758) (www.cigniti.com (http://www.cigniti.com/)), Global Leaders in Independent Software Testing Services, is headquartered at Hyderabad, India.
Cignitis 2200+ career testers are spread across US, UK, India, Australia, and Canada. Cigniti is the worlds rst Independent Software Testing Services Company to be appraised at
CMMI-SVC v1.3, Maturity Level 5, and is also ISO 9001:2008 & ISO 27001:2013 certi ed. View More (http://www.cigniti.com/about-us/)

Company

About Cigniti (http://www.cigniti.com/about-us/)

Management (http://www.cigniti.com/management/)

Investors (http://www.cigniti.com/board-of-directors/)

Awards & Recognition (http://www.cigniti.com/awards-recognition/)

Clients (http://www.cigniti.com/clients/)

Analyst Speak (http://www.cigniti.com/why-independent-software-testing/)

Partners (http://www.cigniti.com/partners/)

Careers (http://www.cigniti.com/cigniti-careers/)

CSR (http://www.cigniti.com/corporate-social-responsibility/)

Consulting (http://www.cigniticonsulting.com/)

Quality Assurance

Functional Testing (http://www.cigniti.com/functional-testing/)

Test Automation (http://www.cigniti.com/test-automation/)

Compatibility Testing (http://www.cigniti.com/compatibility-testing/)

Performance Testing (http://www.cigniti.com/performance-testing/)

Regression Testing (http://www.cigniti.com/regression-testing/)

Security Testing (http://www.cigniti.com/security-testing/)

QC to ALM Migration (http://www.cigniti.com/qc-alm-migration/)

ERP Testing (http://www.cigniti.com/erp-testing/)

Selenium Testing (http://www.cigniti.com/selenium-testing/)

Testing Center of Excellence (http://www.cigniti.com/testing-center-excellence/)

Digital Assurance

Mobile Testing (http://www.cigniti.com/mobile-testing/)

 Digital Assurance (http://www.cigniti.com/digital-assurance-testing/)

Big Data Testing (http://www.cigniti.com/bigdata-testing/)

(http://www.cigniti.com/blog/)
E-Commerce Testing (http://www.cigniti.com/e-commerce-testing/)

Medical Devices Testing (http://www.cigniti.com/medical-devices-testing/)

Game Testing (http://www.cigniti.com/game-testing/)

Quality Engineering

Agile Testing (http://www.cigniti.com/agile-testing/)

DevOps Testing (http://www.cigniti.com/devops-testing/)

Service Virtualization (http://www.cigniti.com/service-virtualization/)

Test Data Management (http://www.cigniti.com/test-data-management/)

24
Shares

Advisory & Transformation

22
Test Advisory Transformation (http://www.cigniti.com/test-advisory-transformation-services/)

Industries

Airlines (http://www.cigniti.com/airlines/)

Banking (http://www.cigniti.com/banking/)

Communications (http://www.cigniti.com/communications/)

E&U (Energy and Utilities) (http://www.cigniti.com/eu-energy-and-utilities/)

Financial Services (http://www.cigniti.com/ nancial-services/)

Insurance (http://www.cigniti.com/insurance/)

Retail (http://www.cigniti.com/retail/)

BlueSwan

Verita (http://www.cigniti.com/blueswan/#Verita)

Velocita (http://www.cigniti.com/blueswan/#Velocita)

Cesta (http://www.cigniti.com/blueswan/#Cesta)

Praxia (http://www.cigniti.com/blueswan/#Praxia)

Prudentia (http://www.cigniti.com/blueswan/#Prudentia)

Cigniti Consulting

Cigniti Sta ng (http://www.cigniticonsulting.com)

Copyright 2017. All Rights Reserved.