Your QA lead says "run a stress test" — but what you actually run is an ordinary load test. The result? The system passes with a perfect score, then crashes during a promotional event because it was never tested beyond its capacity limit. That bug is not in the code — it is in a misunderstanding of testing terminology.
This is not a trivial problem. In our experience supporting QA teams in the banking sector, more than half of them still conflate these two terms. The consequences: the wrong test plan, irrelevant results, and dangerous go-live decisions.
This article breaks down the fundamental difference between stress testing and load testing according to the ISTQB CT-PT standard — complete with a comparison table and mobile banking scenarios you can adapt directly.
Definitions According to ISTQB
Load Testing
From the ISTQB Glossary:
"A type of performance testing conducted to evaluate the behavior of a component or system with increasing load, e.g., numbers of parallel users and/or numbers of transactions, to determine what load can be handled by the component or system."
In short: load testing exercises the system at its expected load — can it handle the number of users and transactions the business projects?
Stress Testing
From the ISTQB Glossary:
"A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers."
In short: stress testing pushes the system past its normal limits — to find the breaking point and confirm it can recover cleanly.
Comparison Table
| Aspect | Load Testing | Stress Testing |
|---|---|---|
| Objective | Verify performance at normal/peak load | Find the breaking point and recovery capability |
| Load | Matches expected load (100% of capacity) | Exceeds expected load (120-200%+ of capacity) |
| Focus | Is the SLA met? | When and how does the system fail? |
| Duration | Normal operating window (30 minutes - 2 hours) | Until the system fails or degrades measurably |
| Resources | All resources available as normal | Resources may be reduced (kill a server, cut memory) |
| Expected outcome | System runs normally, SLA met | System eventually fails — what matters is how it fails |
| When to run | Every release, before go-live | During capacity planning, BCP/DR testing |
| Key metrics | Response time, throughput, error rate | Breaking point, recovery time, failure mode |
| Example | 5,000 users logging in at once (as projected) | 50,000 users logging in at once (10x the projection) |
A Simple Analogy
Picture a bridge designed to carry 10 tonnes:
- Load testing = Sending vehicles across totalling 10 tonnes. Does the bridge stay stable? Is there excessive vibration?
- Stress testing = Sending 15 tonnes, 20 tonnes, 25 tonnes... until you find the point where the bridge starts to crack. And can that crack be repaired?
Worked Scenario: A Mobile Banking Application
Load Testing Scenario
Business projections show 5,000 customers using mobile banking simultaneously during the peak window (08:00-10:00 on working days).
Test plan:
- Simulate 5,000 concurrent users
- Ramp-up: 10 minutes (500 users per minute)
- Steady state: 30 minutes at peak load
- Scenario: login → check balance → transfer → logout
- Think time: 3-5 seconds between actions
Pass criteria:
- Login response time < 2 seconds
- Transfer response time < 3 seconds
- Throughput > 100 TPS
- Error rate < 0.5%
Result: if every criterion is met → the system is production ready.
Stress Testing Scenario
What happens on civil service payday (the 1st of the month) when every customer logs in at once?
Test plan:
- Start at 5,000 users (normal load)
- Increase to 10,000 → 20,000 → 30,000 → 50,000 users
- At each level, measure response time and error rate
- Continue until the error rate > 10% or response time > 30 seconds
- Once you have found the breaking point, drop the load back to normal
- Measure: how long does the system take to return to normal performance?
What you want to learn:
- At how many users does the breaking point sit?
- What fails first? (the database? the connection pool? memory?)
- Does the system crash outright, or degrade gracefully?
- How long is recovery time once load is reduced?
- Was any data corrupted during the stress period?
Other Types of Performance Testing
Beyond load and stress testing, ISTQB CT-PT defines five more. Understanding the differences matters for choosing the right approach:
| Type | Objective | When to Use |
|---|---|---|
| Load Testing | Verify behaviour at normal load | Every release |
| Stress Testing | Find the breaking point | Capacity planning, BCP |
| Spike Testing | Response to a sudden surge | Flash sales, results announcements |
| Endurance Testing | Stability under sustained load | Memory leak detection (8-72 hours) |
| Scalability Testing | Ability to scale as resources are added | Before scaling infrastructure |
| Capacity Testing | Determine maximum capacity | Infrastructure planning |
| Concurrency Testing | Behaviour when the same operation runs in parallel | Deadlock and race condition detection |
For a full explanation of each type, read: What Is Load Testing? A Complete Guide Based on the ISTQB Standard
Tools
Load testing and stress testing use the same tools — what differs is the configuration:
| Tool | Language | Strengths | Best For |
|---|---|---|---|
| Apache JMeter | Java | Open source, multi-protocol, GUI + CLI | The industry standard in Indonesian banking |
| Gatling | Scala | Visual reports, code-first approach | Developers comfortable writing code |
| k6 (Grafana) | JavaScript | Modern, lightweight, CI/CD native | DevOps teams |
| Locust | Python | Easy to learn, distributed | Python teams |
| Artillery | JavaScript | YAML config, cloud-native | Microservices testing |
For a hands-on JMeter tutorial, read: Load Testing with JMeter: A Step-by-Step Tutorial
When Should You Use Each?
Use load testing when:
- Ahead of a production deployment (validating the SLA)
- After an infrastructure change (server upgrade, database migration)
- Periodically, per your audit schedule (POJK 11/2022)
- After a major release or architectural change
Use stress testing when:
- Doing capacity planning (how many servers do we need?)
- Preparing a Business Continuity Plan (BCP)
- Testing Disaster Recovery (DR) — what happens if one data centre goes down?
- Ahead of an event with a traffic spike (flash sale, financial reporting period)
- Evaluating a failover mechanism
Common Mistakes
- Running load testing without stress testing — you know the system behaves normally, but not when or how it fails.
- Using unrealistic load figures — load test targets must come from real production data, not arbitrary numbers.
- Not documenting the environment — results are only valid for the environment they ran in. Record server specifications, software versions, and network configuration.
- Skipping recovery testing within the stress test — knowing the breaking point is not enough. What matters more: can the system recover?
Load and Stress Testing in Regulated Industries
For Indonesian banks, insurers, and fintechs:
- POJK 11/2022 (a Financial Services Authority regulation) requires performance testing and stress testing for core banking systems
- Regulatory stress testing — distinct from technical stress testing. OJK has its own stress scenarios for financial resilience, but IT stress testing is also required as part of Business Continuity Management
- Documentation — every load and stress test result must be documented and auditable
- Frequency — at minimum on any major change, and periodically (quarterly or semi-annually)
Master Performance Testing
To master every type of performance testing hands-on, Frans Training runs the Performance & Load Testing with JMeter programme, covering:
- Direct practice: load, stress, spike, and endurance testing
- Real industry scenarios: core banking, payment gateway, e-commerce
- Bottleneck analysis and capacity planning
- Writing test reports that satisfy OJK audit standards
- A training certificate recognised across the banking sector
Book a free consultation with our team to work out the right programme for your QA and engineering teams.
References
- ISTQB Glossary — Load Testing
- ISTQB Glossary — Stress Testing
- ISTQB CT-PT Syllabus
- ISO/IEC 25010:2011 — Systems and Software Quality Requirements and Evaluation
An Advanced Scenario: E-Commerce Flash Sale
Load Testing Scenario — Flash Sale
Marketing projects 50,000 users hitting the flash sale page in the first 5 minutes.
Test plan:
- Simulate 50,000 concurrent users
- Ramp-up: 5 minutes
- Scenario: open the promo page → add to cart → checkout → payment
- Pass criteria: checkout response time < 5 seconds, error rate < 2%
Stress Testing Scenario — Flash Sale
What happens if it goes viral on social media and traffic runs at 5x the projection?
Test plan:
- Start at 50,000 users (the normal projection)
- Increase to 100,000 → 150,000 → 250,000
- Measure: when does checkout first start failing?
- Drop the load — how long does the system take to recover?
- Are any orders corrupted (paid but not recorded)?
Checklist: Have You Run Both Types of Test?
| Checklist | Load Test | Stress Test |
|---|---|---|
| Load targets based on production data? | Yes/No | Yes/No |
| SLA/acceptance criteria defined? | Yes/No | Yes/No |
| Test environment resembles production? | Yes/No | Yes/No |
| Resource monitoring active during the test? | Yes/No | Yes/No |
| Results documented for audit? | Yes/No | Yes/No |
| Recovery test run after the stress test? | N/A | Yes/No |
FAQ
Do I have to run a load test before a stress test?
Yes, always. The load test validates that the system behaves normally at expected load. A stress test without that baseline has no context — you cannot tell whether a failure came from poor design or simply from extreme load.
What recovery time is acceptable?
It depends on the business SLA. For core banking, recovery after stress usually has to be < 5 minutes. For e-commerce, < 15 minutes is still acceptable. The critical part: the system must recover without manual intervention.
Can stress testing damage production data?
Never run a stress test against a production environment. Always use a separate environment with synthetic data. A stress test is designed to make the system fail — you do not want that happening to real customer data.
Stop Guessing: Master Both Techniques in 3 Days
Is your QA team running both of these tests correctly? Most teams do load testing only and skip stress testing — until the system fails in production during an event nobody planned for.
In the Performance & Load Testing with JMeter course, your team practises directly:
- Load testing with 5,000 concurrent users (a banking scenario)
- Stress testing through to the breaking point
- Spike testing to simulate a flash sale
- Bottleneck analysis and writing up recommendations
Assess your team's readiness — a free 30-minute consultation