Testing Scripts

[bleach]

Is there any sort of way to test scripts without having to actually call in and use a phone line? It's difficult to develope a system when it's already live and online with callers, especially with your sneaky way of binding a code to the mac address to prevent piracy, so you can't load the program on a 2nd machine. Would it be difficult to create some sort of debugging simulator that just reads a voiceguide script and goes through it as if it was a call, accepting user input along the way like dtmf tones? Or are there already applications out there that could be modified to do such a task?

[SupportTeam]

Right now the only way to test the script is to call into the system...

 

At this stage the call simulator which would allow you to test the scripts without the need to dial into the system may be available in about 3-6 months...

[Guest Guest_zackrspv]

Hello.

 

Can we have a status on this? 3-6 months has gone by; is Katalina going to implement this?

[SupportTeam]

There are a number of higher priority projects then the call simulator on the "TO-DO" list right now, so I'd not expect a call simulator for some time...

 

Call simulators do not test the way hardware plays back the files, detection reliability, hardware response times etc - which is where most of the problems are - so in effect it most often gives a false sense of security - on balance it's probably best to properly test the system just as the caller would be hearing it instead of using a call simulator to just walk through a callflow. It's for those reasons that a call simulator is now pretty low on a priority list...

 

Also in most places around the world local calls are free (or just about free) so it's not a big cost issue for many people. Also many VG systems are running on local PBXs - so a test is just a call from another extension on a PBX - again no cost there...

[Guest Guest]

I just use the trial version for testing on my local machine. For most things it works - at least you can get rid of the more obvious bugs

[Guest jusedawg]

Yeah, it would be nice if the editor could at least check the syntax of your code before saving.

[Guest newbie]

We need simulator or script tester/debugger - ANYTHING to test the script. Not having it, is unprofessional. It's also unprofessional to say that it's in a developement for so long.

[Guest Buzby]

Just adding my thoughts to this thread...

 

A call simulator is a massive benefit to those of us who need to test the correct operation and reliability of their external code.

 

My application spends most of its time grabbing keypresses in VoiceGuide, then making dozens of different COM calls into my database to test whether the keypresses are OK or not.

 

Therefore most of my issues rely upon the VB Script code I have written to create the COM calls. Testing this code typically relies upon lots of running of the same segment of code until things work as expected.

 

I have a PBX and use it to place calls into VoiceGuide and test scripts. However, there is obviously a call set-up time (2 rings, then inband processing) and the fact that the telephone is a separate piece of equipment to my laptop. All in all, repetitive switching between telephone and laptop adds time and frustration to the testing process.

 

A call simulator would resolve most of these issues by removing the call set-up time and negating the requirement to switch between devices.

 

I see a call simulator as quite an easy-to-implement feature for VoiceGuide. Surely it would be a small add-on offering a windowed-keypad for the user and sitting somewhere between VoiceGuide and the calls it makes to the Dialogic hardware.

 

In fact, seeing as VG can control voice modems, perhaps someone could cleverly devise some kind of modem driver than passes its calls to a keypad on the desktop and 'fools' VoiceGuide into thinking it is controlling a modem instead? (PS. If someone does this as a commercial product, I would like a share of the royalties!)