20
‘ How To’ and ‘ How Not Too’ Test Payment Systems Divya Murthy Anoop Nair Infosys Limited (NASDAQ: INFY)

‘ How To’ and ‘ How Not Too’ Test Payment Systems

  • Upload
    lalo

  • View
    22

  • Download
    0

Embed Size (px)

DESCRIPTION

‘ How To’ and ‘ How Not Too’ Test Payment Systems. Divya Murthy Anoop Nair Infosys Limited (NASDAQ: INFY). Abstract. - PowerPoint PPT Presentation

Citation preview

Page 1: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

‘ How To’ and ‘ How Not Too’ Test Payment Systems

Divya MurthyAnoop Nair

Infosys Limited (NASDAQ: INFY)

Page 2: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Abstract

2

Payment systems are perhaps the most important, yet volatile components in a financial institution's framework. An efficient payment system is crucial to the functioning of the financial markets and the entities involved.In the past few years there have been several changes in the services offered in the payments landscape due to external circumstances. These changes are usually time bound and thus arises the need to develop quality systems within these stringent timelines. There is immense pressure on the IT departments within banks to provide payment systems which meet the recent regulatory requirements and also incorporate the latest technology trends within the existing legacy systems.Also, the changes in the payments industry in the form of new entrants, regulations, and technologies have resulted in financial institutions adopting new strategies and increasing their technology spend on these applications. The options available for the banks to embrace these new technologies have their own set of challenges to address.• Legacy systems- Though generally stable and a comfortable option for the banks to continue with, they have the drawback of being dated and not being able to integrate with systems built on latest technology.• Vendor applications - Albeit this is an “easy-to-procure-and-use” option for banks, the ability of these applications to cater to the client specific needs of the banks is minimal.Correspondingly, testing a plethora of such systems can assume paramount importance as these systems grapple not just with changes within the organization but also with regulatory and technological changes. This paper highlights some of the best practices that are prevalent in the industry while pointing out a few generic fallacies pertaining to testing payment systems to ensure the applications are stable, reliable and resilient

Keywords: Testing of payment systems, best practices, fallacies

Page 3: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Payments Landscape

3

Custome

r makes a

payment

Custo

mer's bank trans

mits

payment

data

Clearing

Settlement

Payee's bank makes note of payment

Funds

available to PayeeFig 1. Payment Life Cycle

• Payment systems constitute the backbone of the banking and financial industry

• Post the financial crisis, the need for an efficient payment system was recognized

• New Banking Regulations, Payment Channels, New Products – pose a challenge

• Testing involves multiple flows, systems, file formats

Page 4: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

4

Payment Trends and Associated Challenges

Regulatory

Requirements

Multiple Paymen

t Channel

s

Transaction

Volumes

New Product

s

Overworked

Systems

Fraud Detecti

onGlobalization

Page 5: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Why this Paper?

5

• An attempt to highlight some of the desirable and quite a few of the undesirable practices/ methods that testers adopt while testing payment systems

• Create awareness on mitigating poor practices in payment systems testing, thereby reducing the risks that banks are prone to in the event of any casualty that can be attributed to undesirable testing practices.

Page 6: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 1: Dealing with Data complexity

6

Bank A in the Belgium receives an MT202 SWIFT message from Bank X also in the Belgium to be passed on to Bank Y in London to fulfill an MT103 payment instruction.

How will the QA testers validating payments with several possible data combinations ensure through test coverage with optimal utilization of time and effort?

Page 7: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 1: Dealing with Data complexity ( Contd.. )Banks use resident banking software applications or an OTS vendor software

applications/ products, customized to suit its needs.Testers maintain a homogeneous focus on elements like data, value and field.Functional testing of payment systems involves the field by field validation of

all the data coming in from the source/ upstream system, transformations and then finally, transmission to the downstream system.

DDT is a functional testing technique which emphasizes greatly on the reuse of data.

7

Data Driven Testing

approach

• Emphasis on reuse of data• Field to value mapping including

negative scenarios• Doubles up as a traceability

matrix• Found to reduce scripting efforts

by 70% Microsoft Office Excel Worksheet

Page 8: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 2: Prioritization of effort in a time bound scenario

8

There is a major change in a regulatory requirement involving cross currency payments. This would require a significant amount of rework in all the stages of the lifecycle which would result in considerable delay. However, the delivery schedule does not get changed as the regulatory body has made it mandatory for all FIs to adhere to the new norm within a specified period of time.

Page 9: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

9

Scenario 2: Prioritization of effort in a time bound scenario (Contd..)

Delays in previous stages/ frequent regulatory changes affect testing.

Testers are somehow expected to accommodate such exigencies and adapt quickly.

Onus is on the testers to come up with the ideal test bed which:

Prioritizes the scripts Ensures coverage of all

the high priority functional test conditions

Prioritizes the E2E scenarios too

RISK

Page 10: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 2: Prioritization of effort in a time bound scenario (Contd..)RBT prioritization criteria Likelihood of failure Impact of failure

Risk Matrix Quantify risks versus impact Ensures coverage of all high

priority scenarios Higher the priority, earlier its

coverage in the test cycle High severity defects detected

early Contributes to optimal

resourcing Adds to client value

Page 11: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 3: Integrating multiple systems and channels A customer, who holds a Current account in Bank A in US, initiates a money transfer to fund his account in India with Bank B to fulfill an EMI obligation. His account in the US is debited with $ 1000 and the bank promises to credit his account in India in 2-3 working days.

However, even after a week the payment has not reached Bank B. Bank A is unable to figure where the payment is held up while the customer is being penalized by Bank B for delaying his EMI payment. Sounds familiar

ATMInternet

MobileKiosk Smartphone

POS

Gateways

Back Office Integration Server

Authentication Manager

Integration Layer & Channel Manager

Bank’s Back Office SystemsRetail Trading Treasury Corporate

Lending Card Systems Trade Finance

Page 12: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 3: Integrating multiple systems and channels ( Contd..)

Multitude of channels involved in the payments domainE2E Testing provides an insight into the functioning of each

payment application system and validate services, messages, interfaces and business processes.

Payment flow involves myriad systems giving rise to various challenges while doing E2E testing:

Multiple points of convergence of payments channelsApplications developed and tested by different vendors in

different regions/environmentsAvailability of multiple test environments and E2E test

environmentsE2E schedule tracking & monitoring

Page 13: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 3: Integrating multiple systems and channels ( Contd..)

Testing Scope

Define Test Strategy

Timelines

Environment Booking

Stakeholder involvement

Defect Management

Metrics

E2E Regression

E2E Test Methodology

Page 14: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 4 : Effective system performance

A bank has tens of thousands of payments coming in one particular day, as opposed to the few thousands which are usually the norm. The sudden spurt of traffic has resulted in a server crash. How can a bank foresee such situations and react efficiently when such exigencies arise?

Page 15: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 4 : Effective system performance ( Contd..)

Performance/ Stress

Testing

Migration&

Regulatory

Require-ments

Transact-ion

VolumesFraud

Disaster Recover

y

Performance Tests – Ensure systems can take the anticipated volumes within a reasonable time frame

Stress Tests – Identify the break point to help define the switch over/ recovery plan

Need to Performance/ Stress Test driven by

Regulatory Requirements Transaction Volumes Migration New Products Fraud Disaster Recovery

Page 16: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 5 : Securing Payments

Mr. John notices an advertisement from Bank XY while browsing the net which promises some interesting benefits on his account. He follows the link which requires him to login with his ID and password. He browses through the content and gets back to doing what he was doing. The next day, he sees a debit of $ 5000 from his Current account not initiated by him. Who could have initiated this payment?

Page 17: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Scenario 5 : Securing Payments ( Contd..)

Increase in fraudulent activities due to introduction of new technologies and new payment avenues

Tools used by existing QA teams to be analyzed and then the security testing processes, tools to be fit into the current process

Types of testing to be done on Payment systems

Network SecurityDatabase SecurityWeb Application Security

Security Testing

Web Applica

tion Security

Network

Security

Database

Security

Page 18: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

Conclusion

Payment systems expected to absorb and align themselves to the advances in technology, regulatory changes and latest developments in business process reengineering

Processes which are mutually beneficial to FIs and their customersInnovations in payments landscapeTesting these improved systems would prove cumbersome unless

radical improvements and advancements are made in testing practices, tools and processes

Prudence to be exercised in identifying the shortcomings of the existing practices/ systems

Page 19: ‘ How To’ and ‘ How Not Too’ Test Payment Systems

References Infosys project experience Infosys resources (www.infosys.com)