Article 05
Performance testing: from business questions to decision-ready results
Plan workload, scenarios, data, environment, thresholds and observability so results show what to fix first.
Load
250 RPS
p95
780 ms
Errors
0.6%
Example situation
Start with the people using the system
The test reached 1,000 users, but is the system ready?
A high user count means little when the test does not match behavior, lacks pass/fail criteria and misses API, database and infrastructure metrics. A useful test answers a business question, such as whether booking completes during opening traffic.
Summary for business and everyday users
Performance testing: from business questions to decision-ready results
Start with the test reason: validate normal traffic, find limits or prepare for a campaign.
Define thresholds before running, not after seeing results.
Align application and infrastructure metrics with the load timeline.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 04
01 / Define the question
Choose test type from what you need to learn
Smoke tests verify scripts; average-load tests validate normal use; stress tests exceed normal demand; spike tests model sudden jumps; soak tests reveal accumulation; breakpoint tests find limits. One type cannot answer every question.
Evidence to inspect
- Which flow must not fail?
- What are normal and peak loads?
- Are we validating or finding a limit?
- Can test data affect production?
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Define the question
01Choose test type from what you need to learn
Smoke tests verify scripts; average-load tests validate normal use; stress tests exceed normal demand; spike tests model sudden jumps; soak tests reveal accumulation; breakpoint tests find limits. One type cannot answer every question.
- Which flow must not fail?
- What are normal and peak loads?
- Are we validating or finding a limit?
- Can test data affect production?
02 / Build scenarios
02Model behavior mix, not one endpoint
Real systems mix login, browse, search, save, reports and background APIs. Model observed proportions, think time and data that does not distort cache or database behavior.
Tag flows and endpoints so p95 and error rate are visible per group; do not let aggregate averages hide critical transactions.
03 / Pass or fail
03Thresholds connect experience and risk
Define response-time percentiles, error rate and transaction success before testing. p95 represents most users without being hidden by very fast requests, but targets must come from business context rather than copied examples.
Example threshold
A pattern, not a universal standard
Search: p95 below 800ms and errors below 1%; order confirmation: success above 99.5% with no duplicate transactions.
04 / Read the result
04Place load beside metrics from every layer
When latency rises, align it with CPU, memory, event loop, connection pool, slow queries, locks, cache hit, queue depth and external APIs. Load-generator results alone show slowness but not its cause.
Checklist before action
Define the test reason
Build workload from evidence
Prepare test data
Set thresholds in advance
Collect every-layer metrics
Document conclusions and limits
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Engineering
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.