Development, Integration and Testing

So this is where the fun begins. You've nearly died of boredom writing endless documents and continuously reworking the requirements. Finally you get to do something - actually that's not true, mostly the code has been started on ages ago - but now it gets serious.

Development

VoiceXML applications break up neatly into two halves: the VUI and the application. It's pretty easy to fake a back-end and the results of queries or requests that you make. So you can develop a front-end that sounds and feels like the real thing - without any real application behind it. This allows you to check if the application really is what the customer wants. They can listen to the application, interact with it and refine any changes that they want. As long as these are VUI changes, rather than functional changes, then you're ok. However, even if there are functional changes to be made, it's best to find out early.

On the other side, you can develop most of the application without the VoiceXML pages. As a matter of fact, you can pretty much write web page equivalents to all the VoiceXML pages. This allows you to test the whole application using only a web browser - rather than trying to integrate straight away with the VoiceXML browser. Of course the time constraints on the web pages aren't the same as for voice, but you have to save some of the fun for later. Having web pages that offer the same functionality as the VoiceXML pages is also very useful when it comes to debugging applications in a live environment. Rather than having to ring the application, or trying to fake a caller's MSISDN to create their particular error, you can use a web interface to test how the application deals with a particular caller. This is a real time-saver.

Integration

Now it's time to see if all this waffle about modular architectures, reusability and interoperability really works. Mostly it does - just not first time! Debugging a distributed system such as VoiceXML application can be a barrel of laughs. You're going to end up with a bunch of logs open in front of you - particularly if you have more than one server. So you should have your VoiceXML logs open - if there are a lot of calls on the platform, use tail and grep to single out your test call. You may want the access logs of the web server open. Then you'll want the actual output logs of the web/application server. Finally if you're application writes its own logs, which contain more information than just an error, you'll need them open as well.

First off, try and determine if you've got a back-end or front-end error. This isn't always as easy as it should be - sometimes a semantic error in your VoiceXML page is not the result of bad VoiceXML, but the response to a server request. It normally takes a couple of iterations to take care of the first elementary errors. One of my favourite errors, is reading in a non-existent parameter, which I want to save as a javascript variable. I start with code like this:

<% String firstTime = request.getParameter("firstTime");
      if (firstTime == null)
        firstTime = "";
%>

<script>
  var firstTime = <%= firstTime %>;
</script>

After compilation it looks like this:

<script>
  var firstTime = ;
</script>

This throws a semantic error and your app is screwed. One way of getting around this is always to use quotes for javascript variables:

<script>
  var firstTime = '<%= firstTime %>';
</script>

This won't cause any errors - though your application may misbehave because of the missing parameter...

Testing

Boy, can this be boring! There are two levels to testing - the user interface and the functionality. Quite often the functionality can first be tested using a web interface. This allows you to test purchasing items, configuring settings, etc. without the hassle of going through the phone interface every time. (Oh-oh, did I just say "hassle"?) Anyway, this is a really good way to test the basic functionality. If it ain't working over the web, then it won't work over the phone. Obviously the final tests need to be carried out using the phone - but you can get alot of the basics out of the way using the web.

Parallel to this you can test the user interface. First off, this is a case of making sure that all the right prompts are played at the right time for the right caller groups. This is tedious and sometimes requires a lot of preparation to create represetative callers for each possible group. The dialog design basically acts as the reference document, to determine if the prompts are correct. Hopefully aspects such as three <noinput>s or <nomatch>s only have to be tested once, as this behaviour should be consistent across the whole application. This pure interface testing can take some time.

Once you're satisfied that the user interface is behaving correctly, you can either proceed with the integration (i.e. coupling interface and functionality) or if you have good dummy data for your UI, you could move straight to some usability testing. Usability is virtually a must if you've written a speech rec application. In fact, except for the most basic DTMF applications, it's at least worth getting some feed-back from people who haven't designed or written the application.

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums