Netsparker Web Application Security Scanner

What is Scalability Testing?

Scalability testing is the part of non-functional testing where a software application’s performance is tested in terms of its non-functional capability to scale up or scale down the user request load or other such performance attributes.

When any application undergoes performance testing, some of the Scalability Testing attributes are defined below:

  • Response time: It is the measure of the time taken by a web application to respond to a user request. It is the time measured after the hyperlink is clicked on the web page till the new web page is loaded on the web browser. There are series of events that take place after it, such as time taken to send the URL request to web server, time taken by the web server to route up to that webpage, time taken by the browser to download the content and display the required web page to the user. Such Scalability Testing is done to identify the response time of the web server under normal load, threshold load, heavy load and break-point load of user requests.
  • Throughput: Throughput is defined as the rate at which something can be processed. For example, we calculate network throughput as the rate at which messages or packets are delivered successfully over the communication channel. Similarly in case of web server it is the rate at which number of requests is served by the web server successfully.

scalability testing


  • Number of User for performance test: Depending on the application type, it is always tested for the number of users that it can support without its breakdown or busy standby situation. Scalability stats are taken in terms of the throughput when working with different number of users. Usually SRS documents have the threshold or capsize of the users well defined, depending on which the capacity of webserver and hardware are defined which undergo this performance test.
  • Threshold load: As defined above threshold load is the number of user requests that web server could handle with desired throughput. Any load on the application above this threshold load will result in either slow response or resource not found (popular 404 errors).
  • CPU usage: A web application has the source code written in number of programming languages like JAVA, PHP, ASP, etc. CPU usage is the measure of the CPU processing while executing application code instructions. Better the optimized code written at the application code level less will be the CPU usage which will result in better throughput. Every organization has the best programming practice guidelines which are followed to get the best CPU usage results.
  • Memory usage: Like CPU usage, performance test are done to test the memory usage. As we know at machine processing level there is RAM (Random Access Memory) which should be used by the machine or CPU in as much optimized manner as possible. Again best programming practice can help in achieving this target. For example developers are asked to write non-redundant code, less number of hits to database, use of cache, removal of the dead code, no infinite loops, etc. These practices will help to get better scalability stats and hence the better performance by the software application.
  • Network usage: A web application or online application should perform with minimum network contusion or traffic. There should be less network usage with maximum utilization of server response. Some of the practices for better performance involve using compressed packets or messages over communication channel or sending the complete request object instead of multiple parameters in a queue, etc.
  • Web server request vs response: This is the measure of how efficiently the web servers are clustered to do the required load balancing. Performance testing is conducted to evaluate that the clustered environment is uniformly distributing the requests among web servers without bottleneck one web server while the other web server is idle. Such clustered systems should be designed such that the throughput of the overall environment is very high.
  • SQL mini plan: Not just the application code should be optimized but SQL queries should also be optimized. Performance testers go through the application code areas to test the mini plan of the SQL queries. Database machine prepares the set of SQL instructions called SQL mini plan before submitting the request to fetch the output. Optimized SQL queries have the efficient mini plan to fetch the desired result from database in very less time and hence enhancing the throughput and response time of the application. E.g., if any search query is taking lots of time to fetch result from database then performance testers suggests to use the indexes on the table columns to enhance the search criteria but at the same time it slows down the persistence of the new record in the same table, therefore choice of adding indexes on the table column is made selectively.

We have discussed above various scalability attributes which are evaluated before application go live to cover the non-functional testing aspects of an application. Such testing is very important and demands a lot of testing skills at technical level.

Have you got a chance to work on Scalability Testing in your testing carrier, please share the experience to our readers. We hope this post on Scalability testing is useful for you to start working on Scalability testing. Let us know if you have any questions in the comment below.

If you are not regular reader of this website then highly recommends you to sign up for our free email newsletter!! Sign up just providing your email address below:

Don’t Miss Another Article

Join over 10,000 people who get FREE and fresh content from this Blog.

Enter your email address:

Check email in your inbox for confirmation to get latest updates Software Testing for free.

Happy Testing!!!

1 comment to What is Scalability Testing?

  • Sandeep

    This is really a excellent site.


Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>