Why end-to-end testing fails

Many folks they think that end-to-end testing will validate their VoIP environment and make them feel comfortable that a VoIP deployment will go smoothly.

I’m gong to go back to my tried and true analogy comparing a VoIP network to the freeway system.

If you measure how long it takes you to drive to work each day, you can get a baseline of your latency and jitter (variance).

The problem with end-to-end testing is that it’s like you’re driving a car with blacked-out windows: When you arrive at work, you’ll have no idea why your normal 30minute commute took 4 hours.

As a result, you’ll never be able to solve the problem (which is the desired result).

The other problem with end-to-end testing is that you typically have to set up a computer or program at the remote end.  This may be difficult or challenging because hardware needs to be shipped around, and deployed in each remote site.

A better solution would be to do what modern freeway system management does: Monitor every freeway link for performance.  If there’s a slowdown or traffic jam, it’s able to be pinpointed when, where, and why the problem is occurring so it can be remedied rapidly.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: