Testing is essential for the delivery and monitoring of every element of the customer service delivery system. The IVR, a key component of that system, is no exception. Even the most basic customer inputs can lead to problems down the road if there is just one error in the mix.
This fact is only magnified in the financial industry, where customer inputs at any given touchpoint deal with sensitive data and critical transaction info. A system error in this context opens the possibility not only of a frustrating customer experience but of lost funds and exposed personal information. That’s why every part of the system must be tested consistently with meaningful, useful data that mimics the millions of possible scenarios at play in any IVR interaction.
But where do you get that data? In the world of banking and financial institutions, customer information is tightly regulated. The risk of data compromise is too great to allow banks to freely manipulate real customer data to test their systems. And many institutions won’t even allow test data in their production environment.
Banks are thus left to figure out a workable solution for managing test data in a way that produces meaningful results without compromising sensitive customer information. It’s not easy, but it can be done. Let’s look at a few ways.
The Importance of Test Data Management for IVR Success
Banking institutions use IVRs for an array of customer interactions, both over the phone and online. In many cases, these interactions involve customers checking their balances, making payments or receiving important alerts — all without the direct assistance of a bank employee.
If there’s an error at any point in the process, it could result in anything from moderate annoyance to a serious grievance on the part of the customer.
Say a customer calls in to check her balance and receives an incorrect number. She goes on to make a purchase only to find she has overdrawn her account because she didn’t have the correct balance information.
Or, imagine the system fails to send a fraud alert via a customer’s mobile app. He misses the chance to deal with the issue immediately, thus leaving open the possibility for even more fraud on his account.
Constant, ongoing testing helps banks to minimize issues like these. Because of this, financial institutions need a way to consistently test and tweak customer data against system inputs to ensure the process is working as it should.
Protecting Customer Data Is Paramount
Yet, therein lies the problem. Banks can’t use and manipulate real customer data for testing. Major data breaches over the years have led to strict regulations on how institutions can use customer information. Banks are subject to a host of laws such as the General Data Protection Regulation (GDPR), the Gramm-Leach-Bliley Act (GLBA), and the Payment Card Industry Data Security Standard (PCI DSS). Violating any of these can lead to serious legal and financial consequences.
In the context of test data management, that means a bank isn’t free to simply use John Doe’s account to run a test. It’s not even free to use a copy of John Doe’s account that still has all of his relevant financial information. There’s too much potential for exposure or misuse.
The easiest solution would be to create fake accounts that can be tested within the existing IVR environment. But most financial institutions have tightened the reins on creating test accounts in hopes of avoiding embarrassing exposures related to customer account information. In many cases, company policy bars the introduction of any fake data into the system.
Even where policies allow some fake data, it’s usually limited and not all that useful. True system testing requires a vast amount of data — a variety of different customer accounts that can be tested against thousands of potentially simultaneous scenarios. Manipulating even a small amount of fake test data to get useful results is cumbersome and time-consuming. At best, when manually testing this data, banks are covering 20% of potential real-life scenarios.
The Real Challenge: Creating a Useful Testing Environment
This creates a conundrum for financial institutions. A functional, effective and secure IVR system requires testing. These tests need to imitate real scenarios dealing with data that mimic real customers. Yet there are significant constraints on the type of data banks can use for testing.
In fact, that’s only one layer of the problem. The real challenge is much more expansive and goes beyond the data itself to the testing environment as a whole. After all, an IVR system doesn’t exist in a vacuum. It connects to every aspect of a bank’s service environment. As such, you can’t create an isolated IVR environment for testing, or you won’t have the data to test it with.
Beyond that, “testing” itself is a broad term. Within that, there’s regression testing, performance testing, and system monitoring. Each of these demands a different set of accounts that can be manipulated and tested to ensure the system is working. For each one, there must be enough data (account numbers, types, balances, etc.) — and the ability to manipulate it rapidly — to make for meaningful testing.
The real question, then, is not simply how you manage your test data. It’s how you test your environment when it requires data. That’s why simply using a small number of fake test accounts, even when it’s allowed, isn’t sufficient.
How To Build a Secure and Effective Testing Environment
In the banking world, that leaves two basic options for effective test data management: the fully parallel universe or a hybrid setup.
A Fully Parallel Data Testing Universe
Setting up a fully parallel universe is the only truly comprehensive way to address the issue. In this scenario, a bank not only has a set of fake accounts for testing but an entire system that mimics its real production environment.
This setup acknowledges the interconnected nature of the IVR system and its various touchpoints with the rest of the bank’s back-end systems. Because the parallel system mirrors the bank’s production environment, including mirrored customer accounts (with anonymized data), comprehensive testing is possible with no risk of data compromise.
This is a costly option, though, and most institutions won’t go to these lengths. It requires double the efforts of system maintenance, and every change made to the live system must be duplicated on the mirrored one.
The More Likely Scenario: A Hybrid Environment
For most institutions, the more affordable scenario is a sort of hybrid environment. In this setup, there’s a robust test IVR environment that interacts with the production environment in a way that maintains data compliance but still allows for large-scale testing. There are also a small set of test accounts that do not violate any regulatory constraints.
For this to work well, the testing and data manipulation process must be fully automated. That allows for large-scale testing that’s not bogged down by a cumbersome manual workload. It also requires a flexible testing environment that allows for test data to be dynamically adjusted according to each test that’s to be performed. This is a complicated process, but it’s exactly what the Cyara platform can do.
In this setup, a bank can run a whole series of test campaigns that have different data requirements. Before each campaign, the system can automatically request the type of data it needs to run the test. Once the data is ready, the system runs the test and moves on to the next campaign to repeat the process.
A hybrid environment like this allows for a minimal level of fake account creation, and it keeps those fake accounts separate from the production environment. With the right software, the whole process can be done efficiently and in a way that effectively tests the IVR system against a wide range of real scenarios.
For financial institutions, testing and dealing with sensitive customer data will always be an essential part of CX development. To learn more about Cyara and how our software can help your bank build the best environment for your test data management, see what our automated CX assurance platform has to offer.