Want to write automation tool to test voicexml application

Question

Hi , I would like to create a Tool to test vxml application(outbound ) . I want to write test cases for each of the scenarios and use the tool to run over the testcases on the vxml application and get the results .

My idea is to create a inbound application dynamically depending on the test cases and run over the outbound application and get the results ..

Any ideas is appreciated if any one has ever tried to implement any such tools to test VXML application .

Thanks in advance

Baalu

Answer 1

Have you looked into using the Mumble automated test tool from Tellme? You can access information about it from the home page of Studio (http://studio.tellme.com).

---

Tellme retiree

Answer 2

Hammer, or Jigsaw from www.gtn-tech.com if you only have a few hundreds to spare

IVR veteran

Answer 3

Hi Baalu,

I know this is old, but it showed up in my Google alerts...probably when Microsoft updated their copyright.  Maybe the information will help others that stumble on it.

I'm the Architect and Development Manager for Voiyager (www.Voiyager.com).  Our approach is a bit more involved than yours.  Our testing approach was to create a browser and use that to drive applications.  It lets us automatically explore call flows as well as provide an API to write system function tests (directly drive a call by providing caller phrases or tones and see each audio clip and TTS played, form experienced and a variety of other data).  This is probably a lot bigger than you or others that need to build versus buy.

Therefore, the approach I've take in this type of situation is to do what you've suggested.  Write an opposing (inbound for outbound, or outbound for inbound) application.  To keep call flows in sync, I've replaced audio files of humans with audio files of tones being played.  This allowed the script to do a basic DTMF input to verify that it is in the correct portion of the call flow.  Note, this technique may not work on some VoIP systems as DTMF commands are no longer supposed to be inband (audio you hear).  However, if the system is a mix of traditional telephony and new, it may still work.  TIP: encode key data, like balances, into the DTMF output so you can insure that the logic in your application is correct.

I have seen some attempts at the application level to use HTTP test harnesses to drive call flows.  They don't really test the application, but they at least make sure that the page transitions occur.  It will catch larger bugs, but usually not the more subtle or call flow related bugs.