The World of Stressing the Apps aka Performance Testing

I might have hurt the apps’ feelings with my title, but this is what this article is going to be about: stressing apps for results.

The results I am referring to are based on the speed, response time, stability, reliability, scalability, and resource usage of a software application under a particular workload.

That is what, in testing terms, we call Performance Testing.

To simplify this a bit, this is what we look for when testing performance:

• Speed – Determines whether the application responds quickly;
• Scalability – Determines the maximum user load the software application can handle;
• Stability – Determines if the application is stable under varying loads.

What is the reason we have to stress our apps?

Unlike regular testing, where the scope is to find bugs, for performance testing, our scope is to eliminate bottlenecks within our application.

The easiest and most common real-life example of this would be the Black Friday period. That is a moment when a large number of users (more than the regular amount) would access the same website at the same time. This kind of traffic overloads the servers and results in a broken website that would not load to any of the users, causing a so-called downtime that would make the company that owns the product lose a lot of money. 
For example, in one of Amazon’s Web Service downtime, it was estimated that Amazon lost around 1100$ per second of downtime.

You might ask: where do I start?

Based on what we actually need to track, we can go for one of the following types of performance testing:

• Load testing –  is used to check how the app performs under anticipated user loads. The objective is to identify performance bottlenecks before the software application goes live.
• Stress testing – involves testing an application under extreme workloads to see how it handles high traffic or data processing. The objective is to identify the breaking point of an application.
• Endurance testing – used to make sure the software can handle the expected load over a long period of time.
• Spike testing – tests the software’s reaction to sudden large spikes in the load generated by users.
• Volume testing – is used when monitoring the app’s behavior after populating the database with a large amount of data. The objective is to check the software application's performance under varying database volumes.
• Scalability testing – The objective of scalability testing is to determine the software application’s effectiveness in “scaling up” to support an increase in user load. It helps plan capacity addition to your software system.

Performance issue vs. regular issue

How do you know you have found a performance problem and not a regular issue?

Well, some of the problems that we might encounter while testing the performance of an app are:

• Long Load time – Load time is normal the initial time it takes an application to start. This should generally be kept to a minimum. Load time should be kept under a few seconds if possible.
• Poor response time – Response time is the time it takes from when a user inputs data into the application until the application outputs a response to that input. Generally, this should be very quick. Again if a user has to wait too long, they lose interest.
• Poor scalability – This happens when the app cannot handle the expected number of users.
• Bottlenecking – Bottlenecks are obstructions in a system that degrade overall system performance. Bottlenecking is when either coding errors or hardware issues cause a decrease in throughput under certain loads.

Is there anything out there that can help with Performance Testing?

Glad you asked!

There are actually several tools out there that can help us analyze and see the performance of our apps. One of the most commonly used tools is JMeter.

Apache JMeter is an open-source, purely Java-based software. The software is used to perform performance testing, functional testing, and load testing of web applications.

With Jmeter, you can basically create a large number of users that perform a certain task through a so-called Thread Group. This way, you can simulate a heavy load and track the results of pretty much anything you need. Here, you can adjust the number of users, the loop count, and even the delay between users' actions.

And guess what? It is entirely free to use. There is no paid extra feature or something like that. However, you might not enjoy the interface as it can look a bit old school.

But trust me, once you get the hang of it, it does its job flawlessly.

The cool thing about JMeter is that everything is really customizable. From the number of users and in what order you want them to engage with the app, to customize the app’s encoding, and manage the cache and cookies. You can pretty much simulate anything that can happen in the real world, on a website, in terms of user traffic and data processing.

Where are the results I am seeking?

JMeter does not leave you hanging when it comes to viewing the results, either.

There are 2 main ways that you can use to check and interpret the results.

• Listeners, which are of different types, depending on what information we need: all the User runs, an average of all the runs, or a huge graph with a lot of colorful lines, etc.

Source: https://www.oodlestechnologies.com/blogs/jmeter-graph-results-listener/

• Reports, which look a bit nicer and have more graphs.

                           Source: https://www.perfmatrix.com/jmeter-dashboard-report-gui-mode/

To wrap things up

Performance testing is an important process that every QA should incorporate into their skill set, as it is crucial to check how our apps behave in stressful situations before we launch them for the whole world to see.

Our end goal is to keep the user engaged by maintaining a “healthy environment” in our apps.

Remember that there are several tools out there that can help us with this process, so find one that better suits your project’s needs.