First of all, for the software, it is necessary to check up working capacity in the extreme conditions of use, failures in it can lead to big and serious consequences, whether financial or any others, even to the most serious, right up to human lives.

So stress testing is a type of non-functional testing that involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. In other words, applying load beyond the actual load limit is Stress testing.

Stress testing is a type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers.

In simpler words, it is a form of software testing that is used to determine the stability of a given system, but it puts greater emphasis on robustness, availability, and error handling under a heavy load, rather than on what would be considered correct behavior under normal circumstances.

Stress testing is especially necessary for critically important software. Usually, it is better for revealing the stability, availability, and processing of exceptions by the system under heavy load, compared to what is considered correct behavior under normal conditions.

The goals of such tests may be to ensure that the software does not crash in conditions of insufficient computational resources (such as memory or disk space).

The necessity of stress testing is dictated by the following factors:

• In majority most of the systems are designed with the assumption of functioning in normal mode and even when there’s a possibility of increasing the load, its actual increase is not taken into consideration.
• In the case of SLA-contract, which indicates this type of testing being obligatory and the cost of failure of the system under extreme conditions can be very high.
• Detection of some errors or defects in the system functioning is not always possible with other types of testing.
• The testing that was performed by the developer may not be enough to emulate the conditions under which the system failure occurs.
• It is preferable to be ready to handle the extreme conditions of the system than expecting it to fail.
• The investigation of the bottlenecks or particular components with disproportional loading on the system.
• Testing the capacity of the system.

The main goal of stress testing is to reveal application bugs that surface only under high load conditions. These bugs can include such things as synchronization issues, memory leaks, and race conditions. Stress testing allows you to identify the application’s weak points, and show how the application behaves under extreme load conditions.

Spike testing is a subset of stress testing. A spike test is a type of performance test focused on defining or validating the performance characteristics of the product under testing when subjected to workload models and load volumes that repeatedly increase beyond anticipated production operations for short periods of time.

Talking about inadequate load, one can say that, in case of testing the allocated systems, it is necessary not only to consider the actual load volume, consisting of many elements but also their proportions in the total capacity.

The use of such a load in stress tests can also be used to identify the bottlenecks of individual system components.

From the point of view of business development, on one hand, capacity testing is one of the most important areas of stress testing and, on the other hand, is the most difficult in terms of carrying it out and analyzing. Capacity testing is performed in order to determine the safety margin of the system in full compliance with the performance requirements.

While simulating the load for the capacity testing of the system, it is taken into account as the current load in the form of the number and certain proportions of requests simultaneously proceeding to the system, as well as the expected load in the future.

The result of capacity testing of the system is a set of maximum possible load characteristics of the system, which makes the application or system to meet the performance requirements.

This type of testing can cover different time frames:

• a one-time short-term load on the system
• periodical short-term load on the system
• a one-time long-term load on the system
• periodical long-term load on the system with a probability of failure of the system

Stress testing can be performed with a heavy load on the system and the obvious probability of failure in the system outside the context of load testing: then it is called “destructive testing” and appear to be an extreme form of negative testing.

As an example, we might flood a web application with data, connections, and so on until it finally crashes. The fact of the crash might be unremarkable. The consequences of the crash, what else fails, what data are corrupted and so forth, are the results of interest for the stress tester.

Often, it is not possible to manually create the necessary load conditions; therefore, testers tend to resort to:

• Focusing on certain types of transactions, which affects the boundary situations to emerge more often than when load testing is used.
• Using scripts, virtual users and other automated simulators of an intensive working process, that allows exploring the behavior of the software at a peak load.
• Researching of bottlenecks in the system.
• Investigation of error handling process and exceptional situations.

The benefits of stress-testing:

Defines if data can be corrupted by overstressing the system.

Provides an evaluation of how far an application can go beyond the target load, before causing failures and errors in addition to slowness.

Allows establishing application-monitoring triggers to warn about incoming failures.

Ensures that security vulnerabilities are not disclosed by stressful conditions.

Determines the side effects of common hardware or supporting application failures.

Helps to determine what kinds of failures are most valuable to plan for.

The point is that it is often difficult to know how much stress testing is worth applying. Sometimes because stress tests are unrealistic by design, some stakeholders may dismiss test results.

Also, it should be taken into account that is possible to cause application and/or network failures that may result in essential disruption if the test environment is not sequestered.