Browse Prior Art Database

Testing Interactive Voice Response Systems

IP.com Disclosure Number: IPCOM000118236D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 71K

Publishing Venue

IBM

Related People

Nix, CJ: AUTHOR

Abstract

It is difficult to automate logic path and load testing of Interactive Voice Response (IVR) Systems because of the dependency on tone input across multiple lines, normally provided by the human voice, to drive the application in response to voice prompts.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Testing Interactive Voice Response Systems

      It is difficult to automate logic path and load testing of
Interactive Voice Response (IVR) Systems because of the dependency on
tone input across multiple lines, normally provided by the human
voice, to drive the application in response to voice prompts.

      Existing automated systems call the IVR and generate tones to
drive the application, requiring considerable work to match the tones
to the pace and paths of the application logic, and frequently
requiring the application to emit tones to synchronize with the
calling tones received as input.  It also has the disadvantage of
predictability of pace and response.

      The described solution involves designing and implementing the
IVR application in such a way that when an application logic prompts
the caller for key input, the timeout logic, which is triggered when
no keys are entered, is extended to alternatively allow data to be
substituted in the appropriate variables in place of the normal data
converted from the pressed keys.  This capability can be alternated
at will through the setting of a configurable flag or switch to
differentiate between testing and production modes of operation.

      The application is still invoked by a human call or a machine
(or both) generating the calls to single or multiple concurrent
channels, and includes a common timeout routine that is invoked each
time the caller key input has been requested and key collection
performs a timeout.

      The configurable flag is tested in the common timeout routine
and determines whether tone data substitution should take place or
normal processing by returning directly from the common timeout
routine with no action.  If tone substitution does take place, then
the common routine substitutes values in the key buffer variables
that are accessible to the routine.  The specific values are
determined by passing the name...