Menu Zamknij

Automated Contact Center IVR testing

Sławomir Nasiadka

Introduction

I’m a great fan of Contact Center solutions. I work with them every day both as a customer, and as an architect. They have to deliver consistent experience to company’s customers and at the same time hide complex processes that are deployed in the organization. Being first point of contact for the customers, Contact Center solutions has to be built out of systems that are reliable, stable and provide right information at right time. One of the frontend system of typical Contact Center is IVR (Interactive Voice Response). It often delivers Self Service capabilities, helping customers address their needs without waiting for a free agent to handle the call. Its ease of use, consistent behavior and stable functionality is crucial for company’s image. Hence, there is a great need to fully and completely test IVR system and its configuration before first customer wants to use it. As in other IT fields, automatic testing can be used for that purpose as well.

Self Service testing

IVRs must be tested in two aspects: functional and non-functional. Functional testing helps to guarantee that:

    • Self Service features work correctly,
    • There are no dead ends or loops in the IVR tree.

Non-functional tests are mainly about:

    • efficiency,
    • security,
    • consistency.

Most of the time, Self Service tests are conducted manually. That is because there were no simple ways of checking Self Service as a whole. Self Service has its own complex architecture. It consists of telecommunication components and integrates with company’s internal systems. Using typical process of FAT, UAT and integration tests (taken from application development) it is quite easy to automatically test a particular integration point, API or single Self Service function. However, when it comes to combining those functionalities in a voice channel of Contact Center, new challenges appear. E.g.:

    • do prompts play correctly (are they consistent and do they have high quality)?,
    • is IVR behavior deterministic?,
    • does IVR accidentally disconnect calls (e.g. as a result of external company’s system failure in the integration point)?,
    • can a customer easily access particular options in the IVR tree of Self Service?,
    • is moving between options in the IVR tree intuitive and consistent on different levels of Self Service?,
    • what is the maximum amount of traffic that the Self Service handles without performance degradation?

Those questions are valid no matter which technology is used to deliver an IVR. It can be a traditional IVR subsystems (like Genesys GVP, Avaya AVP or Cisco CVP) where whole tree is directly implemented in the form subsystems’ applications. It can also be a voice chatbot solution with a set of rules that uses keywords and context to determine customer intention and reacts accordingly. Moreover, like any other application, Self Services should be regressively tested after each modification. That alone, may take lots of time. It could save many hours of manual work to introduce automatic testing of IVR applications.

IVR testing approach

For automatic IVR testing we need to create an environment that allows to make a phone call to the IVR and during that call, simulate live person behavior. To make a phone call we can use IP connectivity. In today’s world, most of the Contact Center professional systems support VoIP traffic with SIP (Session Initiation Protocol) signalling. Hence, it is enough to create an application that makes VoIP calls and after connection is establish, sends series of DTMF digits. I will show how to use publicly available libraries to create an application performing automated IVR test.

My testing environment consists of:

    • Freeswitch with IVR module activated (by default it is available at number 5000),
    • PC with Eclipse and Java 1.8 installed,
    • jain-sip library attached using maven (https://www.oracle.com/technical-resources/articles/enterprise-architecture/introduction-jain-sip-part1.html)- for SIP stack,
    • jlibrtp library (https://sourceforge.net/projects/jlibrtp/) – for RTP (Real-time Transport Protocol) stack.

I use jain-sip library to create a valid SIP stack. That allows me to create connections in the signaling layer. When, the connection is established, I open audio session (i.e. RTP receiver’s port and separate RTP outgoing stream with silence). In that way I simulate normal callee that doesn’t say anything and just listens to IVR prompts. IVRs often expect calling party to send DTMF digits – e.g. when called needs to choose particular IVR option or enter PIN to authorize. In SIP world there are several ways to send DTMF digits. One of the wildly supported is to use named telephony events (NTE). The method is described in RFC 2833 and makes use of RTP stream. Digits are inserted into the stream as additional packets. Those packets are specially marked according to what has been negotiated during the signalling phase. My application uses NTE and simulates pressing digits by the customer. Digits are send to Freeswitch and the IVR reacts accordingly. Each prompt played by the IVR is saved by the application to a file for further analysis (e.g. using Automatic Speech Recognition systems).

The high level architecture of the application and its interaction with IVR is presented below.

The application code is a bit long to paste it here and I won’t do that. I hope that the description of how the application works and list of libraries allows you to approach the subject on your own.

Summary

I’ve presented basic components of application that automates testing of IVR systems. The application uses VoIP and publicly available libraries for SIP and RTP stacks. Having such application it becomes straightforward to create automatic IVR testing process. That reduces total cost of tests for new features and regression. If you have questions or need help with automatic IVR testing, contact me via Contact form.

Happy coding 🙂