You probably are familiar with the line “Show me the money!” from the movie Jerry Maguire. In the movie, Jerry’s client asks Jerry, his agent, to show him the money. He doesn’t want his agent to talk a good game or make a bunch of promises, he wants results. That line is now used in pop culture to mean delivering results.
How does that apply to your IVR testing? Well, aren’t you a lot more interested in the results of testing — finding issues and defects in your IVR — than you are in tracking how many test cases your testers wrote or how often they dialed your IVR to make sure it worked the way you wanted it to? Of course, you are. But, if that is the case, why are so many IVR testers focused on writing test cases and making manual dials into your IVR, instead of finding issues and defects?
What You Are Actually Paying Your Testers to Do
The reality is that most businesses still manually test their IVRs. And, with legacy manual testing practices, you are paying your testers to write test cases and manually dial into your IVR, and not necessarily for finding issues and defects. You are wasting valuable resources that could be solving real problems and improving the customer experience in the IVR by tying them up with the mundane tedious work of writing test cases and manually dialing the IVR. Even worse, in most cases, they are writing those test cases after the application has already been built or changed based on complicated requirements documents that were completed weeks earlier by a completely different group of people. It’s near impossible for them to write test cases that reflect the actual or complete design. And, not only are they manually writing those test cases, they are also manually dialing the IVR to validate that the results pass the test cases.
That sounds like important work. Everyone knows that you need to test the application before it is put into production — right? Right, but manual testers are weighed down by writing test cases and executing them manually. Moreover, the testing group never seems to get the time they asked for in the project planning process to do the testing. So, they simply can’t test enough to reliably find issues and defects. In most cases, they are only testing what we call the “happy paths.” The happy path is the path that your customers would take if they actually read your design documents and knew how you wanted them to use the IVR. The problem is, customers don’t read design documents and even if they did, they would still find ways of using your IVR that may never have been tested by your testers. So you need to free your testers up to test beyond the happy paths and find any issues and defects before your customers do.
But Wait, We Have Adopted an Agile Methodology
But wait you say, your organization is going Agile and adopting DevOps practices. Doesn’t that make the testing process easier because it is being done more frequently and in smaller phases? It is definitely not easier. In fact, moving to an agile methodology can take a bad situation with regard to testing and make it even worse. In agile methodology you are looking to increase the collaboration of your teams and give them the flexibility to experiment. Writing and executing manual tests does nothing to foster collaboration and the time it takes can seriously limit the flexibility of your teams. And if your testing team feels pressure to execute faster, they may actually end up testing even less, or testing less effectively than they were before you went agile. In these ways, manual testing can actually be a serious impediment to achieving your agile goals.
What You Should Be Paying Your Testers to Deliver
So, is there a better way? Of course there is. Design-driven testing aligns testing with design documents, ensuring that what you are testing is what the designers intended. Moreover, if you leverage the power of automation, you could automatically generate your test cases, for all the valid paths in the IVR, not just the happy ones, right from the design documentation and deliver those test cases to the testers far in advance of the actual testing phase. Taking it a step further, you could automatically execute those tests as well, enabling your testers to execute ten times the number of test cases in a fraction of the time, and with greater accuracy than even the best manual testers. Approaching the process in that way would free your testers up from the mundane and tedious work of building and executing test cases manually. It would also allow your testers to focus on the really important work of finding issues and defects before they negatively impact your customers. And by automating your testing you will be removing yet another impediment in your organization to becoming agile.
And that’s exactly what Cyara Velocity enables you to do. Cyara Velocity removes the tedious and mundane work from you testers so they can leverage their knowledge and expertise in more meaningful ways. Automation is not just about enabling your testers to test faster, they need to test more, and in more effective ways to ensure you root out issues and defects before they go into production. Cyara Velocity is the industry’s first design-driven testing solution for CX, and it enables your testing team to “show you the money” by finding issues and defects. And this, my friends, is the really important work that will help you deliver customer experiences that delight your customers, drive higher revenues, lower costs and improve customer satisfaction. So, free your testers from the mundane, and empower them to show you the results of great customer experiences.
To see how Cyara Velocity can help you, watch this short video or contact us.
