Why Do We Need Stress Testing?

This is the third and the last blog post in this three-part series. If you want, you can read the first and second posts. In these previous posts, we discussed load testing and performance testing. With load testing, we can see how the system behaves when there is too much load. With performance testing, we can analyze all the moving parts of the system and optimize them accordingly. Load testing and performance testing analyze existing parts assuming everything is in tact. But what if a part of the system completely breaks down? How will you know what’s going to happen at that point? This is where stress testing comes into picture.  

What exactly is it?

As the name implies, you stress the system and see how it behaves. Under stress testing, we try to break the system down and monitor its behavior. Various activities are carried out to overload the existing resources with excess jobs in an attempt to break the system down. We also remove some components of the system to see how the system will behave at that point. This is actually what happens when a particular component breaks down, it’s equivalent to not having that component. This is called negative testing (or fatigue testing) and it’s an integral part of stress testing. This testing should capture the stability of the application by testing it beyond its bandwidth capacity.

Show me an example!

Let’s say you have a software which allows users to create tables. A user can input values in the table and perform various related actions. Now, the purpose of our stress testing is to load it with the excess of rows and columns. To do this, we will repeatedly add rows of data, till it reaches its threshold limit of handling large numbers of rows. Now what is going to happen when it reaches the limit? If it freezes or just exits without saving, it would be bad. The behavior needs to be more gracious than this. So as part of the design, the developer will include functionality that says that as soon as the limit is reached, it would simply refuse to accept more data. Perhaps, it will also display a simple message to the user saying that he/she cannot enter more rows. This is actually a really simple example chosen to demonstrate what stress testing is. In real software, there will be thousands of moving components and the testing becomes really intricate and complex.

What do we achieve by the end of all this?

The purpose behind stress testing is to ascertain the failure of a system and to monitor how the system recovers back gracefully. The challenge here is to set up a controlled environment before launching the test so that you could precisely capture the behavior of system repeatedly, under the most unpredictable scenarios. The goal of the stress testing is to analyze post-crash reports to define the behavior of application after failure. The biggest issue is to ensure that the system does not compromise with the security of sensitive data after the failure. In a successful stress testing, the system will come back to normality along with all its components, after even the most terrible break down.

Load testing, performance testing and stress testing are all part of the bigger software testing process. It is not exactly glamorous! If you do it really well, an end user may not recognize or applaud it. But if you fail to do it, you will most certainly see the exact opposite of glamour and applause from your users. It’s not a hero. It’s like a silent guardian, a watchful protector!

————————————————————————————————-