Community
The pressures of time and cost are constant barriers to effective implementation. These pressures can be offset, for example, by spending more money to reduce testing time. Adding to this inherent testing challenge is the increasing complexity of integrated processing systems. But if we invest in tools which increase productivity, we can deliver more quickly and be better prepared to deal effectively with increasing complexity. In our latest article in the ‘Testing Challenge’ series we look at the role of cost in testing payment systems and provide some ideas about how to manage it.
The deployment and operation of payment system technology and the accurate testing of systems is critical to business success in financial services. Whether it’s a major quarterly waterfall software release or this week’s Agile update, bug-free systems are cost critical. News travels fast when something goes wrong, and if it does you must act quickly to minimize costs and reputational damage. Everyone from the CEO downwards recognizes how important this is, so why is it so difficult to get right?
The testing challenge
Let’s focus on costs. In the broadest terms, the following are cost sources for system testing:
Test Tools
Personnel Time
Let’s consider the two components of system testing (new capability testing and regression testing) and how their cost demands often rise over time.
Testing new capabilities
In its simplest form, we are merely testing new capabilities of an existing system using a single, existing test tool (let’s call it the “base” test tool). However, over time, the reality grows more complex, leading to higher costs:
Over time, many organizations wind up with an “organically” grown mix of different test tools provided by external parties, and other testing capabilities developed internally. Maintenance and custom development costs for external test tools, often from multiple vendors, are not easily controllable. The personnel costs of maintaining expertise in multiple tools and developing multiple internal systems are limitless. Personnel costs rise if any test tool is developed internally, since it has to be tested before new capabilities are introduced. Not to mention that any negative test results may imply that the testing tool itself is at fault.
In addition to the increased cost of executing tests for all new systems and system capabilities, the growing complexity of system architecture considerably increases the time needed for system integration testing. Test tools typically simulate a single member of a back and forth message exchange. System integration testing with this type of test tool typically requires that all other systems used in the test message flow are “live”, that is, the systems not under test must be the actual hardware and software system. System maintenance, software problems and configuration problems in any one system disables the integration testing of them all. And having data out of sync between systems causes major headaches.
Regression testing
In its simplest form, regression testing is simply an ever-growing set of tests performed on a single system using a single test tool designed to test that system. A basic set of tests derived from the original system implementation provides the core test cases and new ones are added as each new set of capabilities in a release are added. But, over time, similar challenges arise in regression testing to those in new capability testing.
While regression avoids having to execute the new tests for the release, it requires testing of systems that are not updated. And the complexity of systems integration testing is compounded in regression testing. All systems have to be involved in regression systems integration, and the aforementioned problems of availability and accuracy are compounded. Superimposing the complexity of system integration testing upon the increasing numbers of unit and integration regression tests leads to an unmanageable regression effort.
Summary of Cost Impacts
The costs of the different types of testing discussed above can be summarized as follows:
Purchase or development
Maintenance
Development and maintenance of tests
Test Project Execution
Integration Testing
Tool Training
A Cost-Controlled Approach
While a certain amount of cost in all these areas is a fact of testing life, costs can be controlled as long as a single test environment is sufficient for all test demands. However, when multiple separate systems are part of the overall solution, the cost of multiple tools to test all systems fully and the inability of a single tool to simulate all systems reduces control. The way to regain control in this instance is a single, highly flexible test tool which provides the following cost advantages:
Our experience has led us to develop a test platform which enables organisations to simulate a real world transaction across legacy systems, multi-step transactions, APIs, web services and tokenisation. This helps to reduce cost and removed the barriers to effective implementation.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Kyrylo Reitor Chief Marketing Officer at International Fintech Business
15 November
Francesco Fulcoli Chief Compliance and Risk Officer at Flagstone
Nkahiseng Ralepeli VP of Product: Digital Assets at Absa Bank, CIB.
14 November
Jamel Derdour CMO at Transact365 / Nucleus365
13 November
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.