Spike testing is a type of performance testing used to determine an application's behavior when exposed to extreme traffic variations. In spike tests, the app is revealed to sudden decrease and increase in load. The results are then analyzed based on factors like −
Does the app crash?
Does the app slow down?
How long it takes the app to switch back to normal?
Accumulating test results, the developers determine when and where the application fails and then take necessary actions for performance improvement.
Let's say X University is all set to upload the results on its official site at 1 −30 PM. Since everybody will be expecting their exam results, the load will be extremely high. The performance tester checks whether the site can handle such a sudden increase and decrease of users or not.
Another such example is Good Friday sales online, where the discounts are available only for a couple of hours. If the site doesn't respond to an abrupt spike in heavy traffic, then a business could save a significant amount of money.
The spike test's primary goal is to see how the system acts under an immediate spike in user load. Here are some critical facts spike tests can unfold −
It helps to verify the overall sustainability of an application
It allows in detecting the performance deviation of an app during spike load
It enables developers to identify the system's bottleneck and errors like 500, 504, etc.
It assists in checking the failure rate of financial transactions in ecommerce websites
It ensures the resources such as CPU, disk, and memory doesn't fail during the spike
Another purpose of the spike test is to determine the recovery period of the app between two successive spikes. The aim is to keep the recovery time as low as possible.
Below are the three types of spike test conducted by performance testers −
Random spike test – Random spike test applies to an application that receives frequent spike load in the production environment. The tester applies random spike levels to the server at random intervals.
Constant spike test – Under this test, the app is introduced a constant spike load (same load) after a specific interval.
Step-up spike test – In the step-up spike test, the tester gradually increases the user load to the server in certain intervals. The testers measure the server's response time at each interval and then analyze how much the app deviates from the baseload response time.
The calculation of spike load differs as per the age of the app or website.
For new applications −
Spike testing is primarily optional for new applications as the change of colossal spike load is rare. However, in some cases, it is vital. For example, if a bank or school is introducing its official app, they might expect a sudden spike of user traffic from their existing user base.
For existing applications −
The business analyst analyzes the historical data of an existing app to analyze any past cases of sudden spikes. The number of users for spike load is then decided after carefully analyzing the results. Sometimes, testers can also predict the spike load based on the company's requirements. For example, if the company plans for a flash sale, then the spike load is determined by calculating the total number of registered and active users.
Note − The performance team is not responsible for calculating the spike load for existing apps. Their role is to design the workload model after receiving the business analysts' spike test requirement.
Spike test is done to tune the application in a way to avoid performance issues in the future. Upon identifying a vast spike load, the testing team runs an investigation to identify the root cause by simulating the test case scenarios similar to the performance test environment.
The performance testers prepare the workload by referring to the spike test NFR consisting of a well-analyzed baseload and spike load.
The test is usually executed for 1 hour, excluding the ramp up and ramp downtime. It is used to analyze the application response time, which plays an essential role in the process. Performance testers must also retrieve data about the app's breakpoint, recovery period and types of error detected.
An app might react differently due to a sudden spike- it can go down completely, or some functionalities stop working. This is identifying the error is crucial in the spike test. Once the type of error is detected, it would be easier for the developers to understand the system failure's real cause.
Most performance testers prefer running two identical spike tests in a single cycle. Unless both the tests don't display consistent results, it is not advisable to move on to the next test.
Although spike test is optional in the world of performance testing, it is unavoidable, significantly, when your user base is growing. You can skip it if your app is new to the market. However, if you have a well-established app or website receiving a healthy amount of traffic, you might consider it. After all, a stitch in time saves nine.
Developers suggest two most-used recovery scenarios against spike loads.
Increase server capacity −Try cloud platforms like Azure or AWS to increase your server capacity.
Limit accessibility − Set a cap on how much users can use the app for a specific timeframe. This protects the system from excessive load.
Spike test comes under the same category of load tests but slightly differs in terms of intention. For example, the role of load testing is to find out how the system behaves during heavy and normal loads. Under load tests, the app is exposed to varying loads, whereas, in spike tests, the app is introduced to a sudden rise and drop of traffic.
Stress tests also pose some similarities with spike tests as both foci on the app's performance. However, a stress test is conducted to know how many users an app can take until it breaks down. Under stress test, testers increase the user load in a step-by-step process instead of giving it a sudden traffic blow.