Load and stress testing is the only way to identify some sorts of device level bugs, as it is only under load that certain parts of the system, such as the queuing mechanism, get tested. Many edge events, such as race conditions, are exacerbated under load and happen more frequently.
In the same way, stressing an entire network or part of a network helps to identify the scalability of the solution and to determine its behavior under sub-optimal conditions. Only by overloading a network is it possible to verify that critical services are maintained and that service degradation under overload is graceful and equitable. In particular, stress testing allows Vendors to demonstrate that prioritisation and fairness algorithms in adjacent pieces of equipment work synergistically and do not end up countering each other.
In addition, stress testing may help identify the optimal network architecture for a particular service model. Different architectures show different modes of degradation under stress and what may work well for one service model may be unacceptable for another. It is critical to determine the practical maximum for numbers of subscribers, subscriber range and so on for the particular services offered and to determine the effect of proprietary Vendor features, such as packet classification and prioritisation.
Stress tests simulate worst case conditions, assuring that the network will continue to function under such conditions. Also, stress testing allows Manufacturers to assist Service Providers to correctly size their networks, so as to provide a consistent Customer experience as the number of subscribers increases and to verify that the introduction of new services will not affect the existing ones.
Without the ability to simulate a large network, it is impossible to reproduce an actual Customer’s network. This means that there is no way to validate a Customer’s network without trying it live, and no way to troubleshoot it except by flying support staff onsite.