Guided testing for phone menus


When I think about the types of communication systems that companies use, it seems like phone menus are much more error-prone than email, websites, and other channels. This really isn’t that surprising. You can easily test the functionality of email and web forms by sending an email message, or navigating to and submitting the forms in various browsers. But when it comes to phone prompts and IVR menus, it’s much harder to figure out what to test and how to verify that each scenario is working properly.

Having worked with some of the best web-based PBX systems, I can vouch that the tools for creating IVR menus have come a long way in recent years. From your web browser, you can record the voice prompts, determine what order they’re played in, assign actions to each number, etc. When you’re done, you can even view a visual tree with the various paths a caller can choose from. But things aren’t as simple as they seem. There’s no easy way to see what happens if someone enters an invalid option on a menu, or just holds the line without choosing anything. Sure, there are controls in the PBX software for this, but no easy way to test them.

Thus, creating a phone menu system where customers can’t get confused or stuck requires a lot of manual testing. You have to make up your own test procedures and update them every time the menu structure changes. Here’s how I would fix the problem: The PBX software already knows all the possible options, delays, and paths that a caller can use. Based on this, it could generate a testing checklist that includes each sequence of caller behaviors, and the expected result.

With this information, the user could print out the testing procedure, try each combination on the phone system, and make sure it checks out. Plus, since the testing list is generated dynamically, it’s easy to re-test the new cases after changes have been made. Even better, the test cases could be numbered and the results stored online for ease of reference. Granted, this isn’t a silver bullet, as someone still has to try the test cases (after all, there’s no other way to know if the right sound is playing or a message gets cut off). But this approach would certainly make it easier for PBX administrators to deliver error-free phone menus with less time and stress. Of course, that’s a great thing for the customers using those menus. They’ll run into fewer confusing options and dead ends, which means a greater chance of actually getting the info they need.