How End-to-End Payment Systems Testing Really Ends: Evaluating Performance, Reliability, and Recoverability

When over-stressed systems fail, the resulting errors can quickly (and disastrously) multiply. Performance testing ensures that payment systems can successfully process the anticipated volume of transactions. Stress testing enables organizations to find the breaking point of their systems and ensure, if the worst happens and the system fails, that seamless recovery is possible.

Key Considerations When Planning Performance Testing and Stress Testing

Even though you may agree that your organization needs to conduct performance and stress testing, you may not know how to begin preparing for these tests. Key considerations for planning performance testing and stress testing include the following.

Access to a knowledgeable team

Assembling the right team will do as much to ensure the success of your performance test or stress test plans as any other factor. When developing a test plan, you must gather information and assure cooperation from many others in your organization: database administrators, systems engineers, network administrators, key settlement personnel, and so forth. Getting input from these team members is a critical first step in successful performance testing or stress testing, as your team members can provide valuable suggestions about what and how to test. Equally important is getting your team members committed to the testing process and goals, because your team can help ensure that the proper equipment and personnel are available when test time arrives.

Clear goals and objectives

It’s impossible to know if your testing was successful if you don’t have clear goals before testing begins. A critical step in identifying those goals is defining your project scope.

In performance testing, for example, are you attempting to fine-tune an application, system, or network? Are all your system end-points (devices, interchanges, etc.) required for testing? Performance testing can be as specific as having your developers use a profiler to test a particular routine, modify it, and retest it to see if processing time in that routine improves; or as extensive as having systems engineers monitor the memory and disk I/O during processing of specific transaction types and loads. Regardless of the focus of your performance testing, you must target resource usage thresholds and processing times so you can use those during the test and when evaluating the test results.
In stress testing, for example, are you testing in regard to capacity planning—testing your ability to handle increased transactions due to growth, acquisitions, or anticipated holiday/seasonal peak periods? Stress testing should determine the breaking point of your system as well as examine the usefulness of messages associated with system failures and the ability to recover data associated with the transactions that could not be processed.

Page 3 of 5

< Previous Page 1 2 3 4 5 Next >