While financial institutions agree in principle that electronic funds transfer (EFT) software testing is necessary and important, these principles are not always reflected in the time and resources allotted to doing so.
More often than not, testing is constrained by limited budgets, or squeezed by delivery promises and aggressive deadlines. Unlimited testing is simply not a realistic option. The only manageable course of action is to determine the best use of the limited resources of Quality Assurance/Quality Control (QA/QC) departments, which begs the question: how do you determine that?
Identifying Electronic Payment Events and Evaluating Probability
You likely already have a list of events that you want to test before moving a new feature or release into production. How do you begin to prioritize those EFT tests? First, you evaluate your list in terms of which events potentially have the most severe financial impact on your financial institution, causing losses that directly affect the bottom line.
Ranking Events According To Impact
Let’s take a look at how best to categorize the top three priority events you will likely identify when prioritizing your testing:
Priority one events represent testing standard functionality of the system, including: withdrawals, transfers, authorizations, purchases, returns, PIN checking, cardholder verification, and reversals. A financial institution stands to suffer the greatest losses should something go awry here, such as when the system functions but in a compromised condition. The financial institution can be assessed switch penalty fees for non-availability, or a compromised system can dispense money in violation of normal safeguards, resulting in substantial losses.
Problems occurring during daily standard operations will have the greatest financial impact on the institution, and so must be assigned the greatest focus or largest share of test resources.
These events test system functionality involving velocity limits, hot cards, or address verification. As these are some of the major avenues of fraud, these events can also have a significant financial impact on your institution. While incorrect functioning of an application during these events will not normally stop system operation, problems here can cause substantial financial losses. Priority two tests guard against failures that will result in an unacceptable loss of functionality. They must be run as soon as practicable. Priority one and two tests should be executed immediately before deploying the application in production.
Lastly, priority three events place a financial institution’s customer applications in an operationally compromised condition, with a diminished capacity to process transactions. Perhaps an ATM or kiosk is declining all transactions or a fault has occurred that may not be fatal, but the defective terminal-driving application takes the unit out of service. Similarly an institution may experience periodic communications failure to a POS/ ATM authorization network, and its stand-in algorithms fail due to inadequate testing.
By determining which tests are critical to effective operation, and then prioritizing those tests to take maximum effective advantage of your EFT testing resources, your organization can ensure that applications are deployed with a minimum of “undesirable features” (commonly known as bugs). With careful planning and prudent use of time and personnel resources, your organization can implement upgraded and new feature-rich applications with fewer post-production headaches.
For more information on how to identify electronic payment events and prioritizing your testing, download our white paper, Playing the Numbers: Assigning EFT Testing Priorities.