How To Get More Complete Test Coverage

We recently added a simple feature that makes it easier to achieve more thorough coverage automatically.

On the RCG, the config file that maps a physical port to the named port you use in a script is called portmap.conf. You can have multiple mappings configured in the file, each with a unique name. And you can choose between which portmap is active when you launch a test suite. In our upcoming release, you can list multiple portmaps on the command line.

You can run a custom test suite to be run with various port combinations — kick off an three hour long test suite with ten different portmaps on Friday evening and not have to worry about relaunching the test, touching config files, or changing cables every few hours over the weekend.

Click here to read this article…

Why Do Experts Plan For Failure?

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:

Click here to read this article…

Tunable Call Delays on the Rimay Call Generator

One tricky aspect of getting automated call testing to work properly across different switches and deployments is that different delays and timeouts are required in various places throughout the script library. This is even harder when targeting different international phone systems.

For example, when we take a phone port off-hook, we sometimes have to be careful to avoid immediately performing operations on that port. It needs a slight delay when we’re on a VoIP system to give the RTP stream a chance to start. Otherwise if we slam it with DTMF right away we’ll lose a digit or two. On a pure POTS system, we can reduce the delay.

Sprinkling these delays throughout the script libraries would be a nightmare…

Click here to read this article…

Step Outside the Call Generator to Force More Failures

The bad news is that the bugs that are left are hard to find. Forcing external failures during call generator testing will help flush them out.

Click here to read this article…

Use a Call Generator for Robustness Testing

Sometimes a feature is broken in a way that is not immediately detectable by the call generator. For instance, let’s say some call flow causes a memory leak in the switch. The call will work hundreds or thousands of times, but at some point the entire switch will stop working — and the cause won’t be obvious.

You want your switch to crash and burn in your lab, not in the field. Let’s look at three types of robustness testing.

Click here to read this article…

The Secret to Managing the Voice Test Matrix Explosion

There are a huge number of possible test cases for even a relatively simple telephony feature when multiple interop combinations are involved. How do we manage all of this?

Click here to read this article…