Networks are typically not well behaved. They introduce errors. They go down. They drop packets or delay them by varying amounts, duplicate them or swap them around. Access links introduce crosstalk, RFI, impulse noise and white noise. And your solution has to work in spite of it.

You must know in advance of release or deployment if your system can:

• Maintain quality of experience (QoE) as represented by transaction response times, throughput, MOS, VMOS, R-Factor, MDI or other relevant metrics in a realistic network environment
• Deliver acceptable service availability under adverse network conditions
• Quickly isolate the source of a problem in a multi-vendor solution
• Detect an outage or unfavourable network condition and failover to a backup link or system
• Minimize or compensate for realistic network conditions, such as jitter, latency and loss
• Operate as expected during disaster conditions

A customer-found problem is much more costly, in terms of revenue, support and customer confidence, than a problem detected and corrected before release or deployment. The networks of today and tomorrow continue to increase in number of users, bandwidth, services and complexity. The test bed must realistically reproduce this complexity and scale.

Your solution must perform in a potentially hostile network environment. If your test system can’t deliver this level of realism, you can’t have the assurance that the system will deliver acceptable performance when it is deployed and succeed in the marketplace.