8

I have to test an DTMF tones via keypad with toll free number, which has a company IVR automated response system. The IVR allows the user to login to the system and user can know account balance, talk to operator and can raise customer complaints/requests etc. It has menu options and can exit. There are many fields and each field has min-max value validation. System prompts error messages on incorrect entries.

I have tested some basic features but i am not satisfied as i am out of test ideas for such type of testing. Please suggest something.

5
+25

IVR (Interactive Voice Response) applications allows customers to call and navigate through various instructions to Login, check on account, pay bills, order service, Customer call, Raise complaints etc.

IVR applications interacts with the caller to determine (via collection of customer entered dtmf digits) who is calling and the reason for the call.

The IVR can also provide automated services to the customer e.g. Automated Bill Inquiry. The IVR acts as a play-and-collect box where the only call routing logic exists to provide fall back routing capability. The IVR performs a database lookup based upon the collected digits and passes the customer data to the CTI infrastructure associated with the call.

Example of IVR architecture:

IVR


Testing all of these IVR systems poses a number of challenges that you don’t often encounter testing other types of applications.

Following are some points which needs to be taken care at the time of testing an IVR application:

  • Account Login scenario tests for User & Administration account:

Test System login scenarios for user & Admin perspective.

  • Pushing the keys of a phone to send DTMF digits:

The DTMF tone is the basic unit used to communicate with and take control over an IVR system. A caller sends the DTMF tones by pressing appropriate keys on a touch-tone phone to move through the menu tree of the IVR system. This menu can be a complicated maze of menus, branches and choices. Complex systems of this type require in-depth testing to ensure that customers are not confused or become stuck without a defined exit.

  • Distinguishing between different languages:

Advanced IVR systems offer caller-selectable languages in which to play announcements.

  • Speaking, listening and understanding voice prompts:

Many IVR systems do not only accept caller interactions with DTMF tones, they are increasingly capable of recognizing voice prompts spoken by the caller.

  • Rating the voice quality of an announcements:

IVR system announcements must be of good quality. They must be transmitted clearly to ensure the caller can understand every word.

  • Behavior under load conditions:

An IVR system can be put under very different load conditions once it is deployed in a live network (e.g., during a tele-voting event, when many callers setup up a call within a very short time). Thus IVR systems must be tested under different load conditions prior to their deployment to ensure:

  • The IVR system works correctly under real load conditions in a live network.
  • The IVR system recovers properly from overload conditions
  • The IVR system is stable over a long period of time
  • Call tracking and report testing
  • Logging:
  • The source of the message.
  • Each step in the path it takes to reach the destination.
  • When and how it reaches the destination.
  • What, if any, errors were encountered and the nature of those errors.

With your logs are functioning as desired, anytime you run into an issue you can check the logs to find the root cause of the issue.

For References :

  1. Test IVR app

  2. Optimus IVR Testing

2

I'm not experienced with testing this type of systems either, but I'd start out by drawing a state diagram of the IVR menu and testing whether the user inputs trigger expected transitions (i.e. navigating through the menu).

I'd definitely also check if invalid / unexpected inputs are handled correctly (tones not expected in the given menu, series of tones).

Since this is a financial system, I'd take a very close look at the authentication step. What types of inputs does the login "menu" expect? What happens if I provide wrong credentials?

The possibility to talk to the operator also looks interesting. Can the operator drop me back to the IVR system? If yes, where do I land? In the last submenu I visited? Maybe some other place?

  • 1
    Also consider administrative functionality. There are features hidden from the normal user that allow an Admin to set up or change the system. Do these features work? How easy is it to break into the system and make free phone calls? The manuals for any IVR system are probably online and can be researched by bad guys. Default passwords are a security risk. – Jerry Penner Dec 23 '16 at 15:13
0

We are using a tool that "crawls" through the IVR, either with DTMF (Easy and automatic) and with Voice (needs some baby sitting on the prompts). Tests all kinds of things, such as rating voice quality, grammars, etc. But, more importantly is systemically, without subjectivity, maps the IVR visually, with all the data it accumulates. The data then becomes a test cases, and you can verify the current IVR solution, as well as let it test when you make modifications and pre-test prior to production, as well as in production. Way more efficient than a human.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy