Scalability testing
Scalability testing measures how a system's capacity changes as the load placed on it or the resources given to it grow. A team raises users or data volume in steps, or adds servers and CPU, and records whether throughput and response time improve in proportion, level off or get worse. The result shows where growth stops paying off.
The longer version
The test runs in two directions. Pushing the load up in steps shows the point where response time starts to climb faster than the number of users. Adding resources at a fixed load, such as a second application server or a bigger database instance, shows whether capacity rises with them. Plotting throughput against either one produces a curve, and the shape of the curve is the finding: a straight line, a plateau, or a decline.
Plateaus usually have a specific cause. A single database writer, a lock shared by every request, a connection pool with a fixed size, a cache that lives on one node or a session pinned to one server will all leave a second machine mostly idle. Doubling the servers does not double throughput when every request waits for the same row, and a scalability test is how a team learns that before the invoice for the extra servers arrives.
A load test asks whether the system copes with the expected number of users. Scalability testing asks what happens to that answer when the number or the hardware changes, so its output feeds capacity planning, such as how many instances next year's traffic needs, rather than a pass or fail for one release. Because the output is a curve and not a verdict, the test is often repeated after an architecture change to see whether the shape moved.
Common questions
What is scalability testing?
Scalability testing is a performance test that shows how a system's capacity changes as load or resources grow. The team steps the load up or adds resources and records whether throughput and response time scale in proportion.
What is the difference between vertical and horizontal scaling in a scalability test?
Vertical scaling gives one machine more CPU, memory or disk, while horizontal scaling adds more machines behind a load balancer. A scalability test can try both and compare how much capacity each addition buys.
How is scalability testing different from load testing?
Load testing checks behaviour at one expected volume. Scalability testing repeats the measurement at several volumes or resource sizes to see how the result changes as they grow. Capacity planning is built on that change.
What causes a system to stop scaling?
A shared bottleneck is the usual cause: a single database primary, a global lock, a fixed-size connection pool, or state kept on one server. Adding machines in front of the bottleneck leaves throughput where it was.
When is scalability testing worth doing?
Scalability testing is worth doing when growth is expected and the architecture leaves it unclear whether the system will cope, for instance before a planned expansion into new markets or an infrastructure migration. A small internal tool with a stable audience gains little from it.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.