The goal of testing is finding failures, right?
Then we should plan for the inevitable failure and make sure we are going to gather as much information as possible. When you are armed with all the right info, you will be able to find the root cause and develop a fix quickly and easily. Otherwise testers and developers wind up in an endless cycle of “can you retest it and capture X?” Half the battle — usually more than half — is simply reproducing the problem and figuring out what is really broken.
We’ve built a great feature into the RCG-4001. It captures, for every test:
- An audio recording, in a .wav file, of what each POTS port on the RCG “hears” during the test.
- A capture of all of the network traffic seen at the RCG’s network interface in a .pcap (wireshark compatible) file.
- Syslog messages from the DUT — you just have to configure the DUT to send syslog messages to the RCG.
- A log of all of the RCG’s actions — debug information from the test scripts.
- The RCG config files that were in effect for the test — so you can easily reproduce the failure with the exact same configuration.
- The source of the script that was running — so you can easily reproduce the failure with the exact same actions.
All of those pieces get put into a ZIP file and saved on the RCG so you can easily copy it into your bug database when you find a broken call flow.
This feature is awesome. That’s not just coming from me — our feedback so far has been enthusiastic. Once you’ve used it, you’ll wonder why you spent so much time in the dark ages.
Here’s a simple but very usable setup that enables the use of this feature:
In this diagram, the DUT is connected to the softswitch through a managed ethernet switch. An old-school hub would work just as well — the point is that the RCG should be able to sniff the VoIP traffic. If a switch is used, configure it so that it mirrors all of the traffic going to and from the DUT to the RCG’s port. This also provides an ethernet connection between the DUT and the RCG for syslog traffic, if your DUT supports it.
And then when something breaks you get a pretty picture like this:
Whoops! The device is sending *67 without a DN and the switch doesn’t like it. We can give the ZIP file containing this to the development team, and they’ll be able to get a fix without needing to ask for more information.
Related posts:
