Key takeaways
- Load, stress, spike, soak (endurance), volume, scalability and capacity testing answer different questions; passing one says nothing about the others.
- Load testing checks the expected peak. Stress goes past it. Spike is a sudden burst. Soak is normal load held for hours. Volume grows the data, not the users.
- Soak testing finds leaks that a short run cannot, and spike testing finds recovery behaviour.
- Pick the type from the risk you are trying to retire.
Performance testing types are the different ways of loading a system to answer different questions: does it meet its targets at the expected peak (load), where does it break (stress), does it survive a sudden burst (spike), does it stay healthy for hours (soak), does it cope with much more data (volume), and what will it take to grow (scalability and capacity). The definitions below follow the ISTQB Certified Tester Performance Testing syllabus, so they match the dedicated posts linked in each section.
What is performance testing?
Performance testing measures how a system behaves under a defined workload: response times, throughput, error rates and resource use. It is not only about making a page faster. It tells you whether the system holds up under the conditions you expect, and what happens when those conditions are exceeded.
Teams run it for four practical reasons. Slow or failing pages cost users and revenue. Finding a bottleneck before release is cheaper than finding it in production. Knowing the limits lets you plan for growth. And regular runs catch regressions in servers, networks and databases when a change lands.
Performance testing types at a glance
| Test type | What changes | Question it answers |
|---|---|---|
| Load testing | Users ramp to the expected level and hold | Does the system meet its targets at the traffic we expect? |
| Stress testing | Users climb past the expected peak | Where does it break, how does it fail, and does it recover? |
| Spike testing | Load jumps suddenly, holds briefly, drops back | Does it survive a sudden burst and return to normal? |
| Soak (endurance) testing | Normal load held for hours | Does anything build up over time, such as memory leaks? |
| Volume testing | The stored data grows; users stay fixed | Does it still perform when the tables are much larger? |
| Scalability testing | Load grows beyond today’s requirements, often with more resources | Can the system meet future requirements, and what does it take? |
| Capacity testing | Load rises until targets are no longer met | How many users or transactions can it support while meeting its targets? |
Load testing
Load testing applies the expected workload, up to the forecast peak, and checks that the system meets its performance targets. A retail site preparing for a seasonal sale would simulate the browsing and checkout traffic it forecasts and watch response times and errors. It finds the bottlenecks that only show with concurrent users. For the details and the contrast with the next type, read load testing vs stress testing.
Stress testing
Stress testing goes past the expected peak, or reduces the resources available, to find the breaking point, the way the system fails and whether it recovers. The question is not only “what is the maximum” but “does it fail safely”: a payment service that rejects requests cleanly at overload is better than one that corrupts data. The comparison post above covers how stress and breakpoint tests differ.
Spike testing
Spike testing applies a sudden, large increase (or drop) in load and then returns to a steady state. A news site that gets linked from a front page is the usual picture. It shows whether autoscaling reacts fast enough and how quickly latency recovers. See spike testing in performance testing for a k6 and JMeter walk-through.
Soak (endurance) testing
Soak testing, also called endurance testing, holds a normal load for a long time, many hours or days, to find problems that only appear with time: memory leaks, exhausted connection pools, growing queues and disk filling with logs. A short test cannot show these. The full method is in endurance testing (soak testing).
Volume testing
Volume testing keeps the user count realistic and grows the data instead: bigger tables, more files, deeper queues. It answers whether the application still works in two years, when the database holds far more rows. See volume testing in software testing.
Scalability and capacity testing
These two are defined separately in the ISTQB syllabus. Scalability testing evaluates whether the system can meet efficiency requirements beyond those it has today, for example after a planned growth in users. Capacity testing finds how much load the system can take while still meeting its targets, which is the number a stress test lets you state. Neither needs a separate tool: both are load tests run with a different question and a different stopping rule.
How do I pick the right performance test?
Start from the risk. If a launch or sale is coming, run a load test at the forecast peak, then a stress test to learn the margin. If traffic can arrive in bursts (a newsletter, a viral link), add a spike test. If the service runs for days without a restart, add a soak test. If the database will grow, add a volume test. A smoke test is a different thing again: a quick check that the system runs at all, see smoke testing.
Running a basic load test
For scripting, Apache JMeter is a common open-source choice. A basic HTTP GET sampler looks like this in the test plan file (the .jmx):
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="Sample HTTP Request" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments">
<collectionProp name="Arguments.arguments">
<elementProp name="param1" elementType="HTTPArgument">
<boolProp name="HTTPArgument.always_encode">true</boolProp>
<stringProp name="Argument.value">value1</stringProp>
<stringProp name="Argument.metadata">=</stringProp>
<boolProp name="HTTPArgument.use_equals">true</boolProp>
<stringProp name="Argument.name">param1</stringProp>
</elementProp>
</collectionProp>
</elementProp>
<stringProp name="HTTPSampler.domain">www.example.com</stringProp>
<stringProp name="HTTPSampler.port">80</stringProp>
<stringProp name="HTTPSampler.protocol">http</stringProp>
<stringProp name="HTTPSampler.path">/api/test</stringProp>
<stringProp name="HTTPSampler.method">GET</stringProp>
</HTTPSamplerProxy>You normally build this in the JMeter GUI rather than by hand. Change the domain and path to point at your own test environment. The shape of the load (how fast users arrive and how long they stay) is set in the thread group, see the JMeter ramp-up period.
Running these tests with LoadFocus
LoadFocus runs load tests for websites and APIs from 25 cloud regions (the product page, October 2026), and can run JMeter or k6 scripts you already have. Results stream in live with response time, throughput, percentiles and error charts, and you can set pass/fail thresholds on P95 or P99 response time, error rate and throughput. A GitHub Action and a Jenkins plugin can fail a build when a threshold is breached, which is how a load test becomes part of CI/CD. For existing JMeter plans see JMeter load testing in the cloud.
Frequently Asked Questions
How many types of performance testing are there?
There is no single official count. The ISTQB performance testing syllabus defines load, stress, spike, endurance, scalability and capacity testing, and volume testing (data growth) is commonly listed alongside them. The four most often named are load, stress, spike and soak.
What is the difference between load testing and performance testing?
Performance testing is the umbrella term for every test of speed, stability and scalability under a workload. Load testing is one type of it: the expected workload, checked against targets.
Is endurance testing the same as soak testing?
Yes. Both names describe holding a normal load for a long period to find leaks and gradual degradation.
What is performance testing in QA?
It is the part of QA that checks non-functional behaviour: how fast and how stable the application is under a stated workload. It sits next to functional, security and usability testing, and its results are compared against agreed targets before release.
Which performance test should I run first?
Run a smoke test to confirm the script and the environment work, then a load test at the expected peak. The results of that run tell you which of the other types matter most.
Sources
- ISTQB Certified Tester Performance Testing syllabus v1.0, section 1.2 (definitions of load, stress, spike, endurance, capacity and scalability testing): istqb.org (read October 2026)
- LoadFocus product pages: loadfocus.com/load-testing and loadfocus.com/jmeter-load-testing (read 2026-10-23)
