A performance test checks how an application behaves under a defined load — how fast it responds, how many resources it consumes, and at what point it stops working correctly. Unlike functional tests, which check whether an application works correctly, performance tests check whether it works correctly fast enough, and with enough concurrent users.
Quick Overview
What you’ll learn:
- How the main types of performance tests differ
- A table of use cases for load, stress, and spike tests
- A step-by-step plan for a first performance test
- The most common mistakes teams new to performance testing make
Who this article is for:
- Testers and QA engineers just starting with performance testing
- Developers responsible for application performance before a production release
- Project managers planning a time budget for testing before a major rollout
Reading time: 6 minutes
The Main Types of Performance Tests
In its Foundation Level syllabus, ISTQB defines performance testing as one form of non-functional testing, covering several distinct subtypes that differ in purpose: a load test checks application behaviour under expected, realistic load; a stress test checks behaviour under load beyond normal conditions, up to the point of failure; a spike test checks the response to a sudden, sharp increase in the number of users.
Each test answers a different business question — a load test tells you whether the application will hold up on a typical day, a stress test tells you where the performance ceiling is, and a spike test tells you whether the application survives a sudden surge in traffic, during a marketing campaign, say.
Types of Performance Tests — Compared
| Test type | Purpose | Example use case |
|---|---|---|
| Load test | Checking behaviour under expected load | Simulating a typical day of site traffic |
| Stress test | Finding the point where the application stops working | Establishing the upper limit of infrastructure scalability |
| Spike test | Checking the response to a sudden surge in users | Simulating traffic during a product launch or promotion |
| Soak test | Checking stability under sustained load | Detecting memory leaks over many hours of operation |
A Step-by-Step Plan for a First Performance Test
- Define a specific test goal — are you testing behaviour under typical load, or looking for the scalability limit; different goals need different scenarios.
- Set realistic load parameters — the number of concurrent users and their behaviour pattern should be based on real production data, not guesswork.
- Choose a test environment as close to production as possible — testing on an environment much weaker than production produces results that are hard to interpret.
- Run the test and monitor key metrics — response time, CPU and memory use, error rate under load.
- Interpret the results against the defined goal and document the findings — raw numbers with no reference to an acceptable threshold (a maximum response time, say) don’t tell you whether the application “passed” the test.
The Most Common Mistakes Teams New to Performance Testing Make
Common mistakes include: testing on an environment unrealistically different from production, no clearly defined acceptance threshold set before the test runs (which makes an objective assessment difficult), and testing only the “happy path” without accounting for scenarios where some requests fail — real production traffic is never one hundred percent error-free.
When to Introduce Performance Testing in the Development Cycle
A common organisational mistake is putting off performance testing until the very end of a project, right before a production release — at that point, finding a serious performance problem (in a database’s architecture, say) is very expensive to fix, because it means revisiting earlier design decisions. Introducing basic performance tests earlier in development, at a smaller scale and with every significant architecture change, catches performance regressions before a fix becomes costly.
A good practice is automating a simple load test as part of a CI/CD pipeline, so every significant code change is automatically checked for its impact on key endpoints’ response times — that doesn’t replace a full test before a major release, but it catches the most obvious regressions as they happen, before they accumulate into a problem that’s hard to diagnose.
Read Also
- QA Engineer Skills: What You Need to Know in 2026 — the broader QA skill set that performance testing fits into
- How to Become a QA Engineer in 2026: Complete Career Path — a broader look at the QA career path, including performance testing
Build Your Skills
This topic connects to the JMeter Fundamentals: Performance Testing and Web Application Performance Testing With JMeter courses. Check the program and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
How does a load test differ from a stress test?
A load test checks application behaviour under realistic, expected load — it answers whether the application will hold up on a typical day. A stress test raises the load beyond normal conditions, up to the point of failure, to find the scalability limit.
When is it worth running a spike test?
Ahead of events that generate a sudden traffic surge — a product launch, a big marketing campaign, a sale. A spike test shows whether infrastructure can handle a sudden, rather than gradual, increase in users.
Which environment is best for performance testing?
An environment configured as close to production as possible. Testing on a much weaker development environment produces results that are hard to translate credibly into how the application will behave in production.
Why is a missing acceptance threshold a problem?
Because without a threshold (a maximum acceptable response time, say), the raw numbers from a test don’t say whether the result is good or bad — the team has no reference point for deciding whether the application “passed” the performance test.