5 exercises — practise distinguishing load, stress, spike, and soak tests; interpreting P99 latency; and writing measurable performance acceptance criteria.
0 / 10 completed
1 / 10
A QA team wants to simulate a flash-sale scenario where API traffic increases from near-zero to 10,000 requests per second within 30 seconds. Which performance test type describes this scenario?
A spike test specifically simulates a sudden, extreme traffic surge — not gradual increase, not sustained load.
A load test runs at expected normal or peak levels to confirm SLAs under realistic conditions. A soak test (endurance test) runs moderate load for extended periods to surface memory leaks and connection pool exhaustion. A stress test increases load gradually to find the system's breaking point. A spike test is the correct answer: it introduces an abrupt, dramatic increase in a very short time window — exactly like a flash sale or viral event — to test auto-scaling, queue management, and failure behaviour.
Key vocabulary:
• Spike test — sudden, extreme traffic surge; tests auto-scaling and failure recovery
• Load test — confirms behaviour under expected production traffic levels
• Stress test — gradual overload to find the system's breaking point
• Soak test (endurance test) — sustained moderate load over hours/days; detects memory leaks
• Auto-scaling — automatic provisioning of additional compute resources under increased load
2 / 10
A performance engineer reports: "Our payment API's throughput is 2,400 RPS." What does this metric measure?
Throughput measures the system's processing capacity — how many requests it handles per second.
Option A describes Time to First Byte (TTFB) — a latency-related metric. Option B describes response time — the total elapsed time for a complete transaction. Option D describes network latency or ping — a network-level metric independent of application logic. Throughput (measured in RPS, TPS, or requests/min) indicates how many operations the system successfully completes per unit time — a key capacity metric. High throughput with low error rate indicates a healthy, scalable system.
Key vocabulary:
• Throughput — requests/transactions successfully processed per second (RPS / TPS)
• Latency — the delay between a stimulus and a response; often used for network-level timing
• Response time — total elapsed time from sending a request to receiving the complete response
• TTFB (Time to First Byte) — the time until the client receives the first byte of the server response
• RPS — Requests Per Second; the standard unit for API throughput measurement
3 / 10
A performance report states: "The P99 response time for the /api/checkout endpoint is 1,240 ms." What does this mean?
P99 (99th percentile) means 99% of requests fall at or below this threshold — not an average, not a failure rate.
Option A reverses the meaning: P99 is a success metric, not a failure rate. Option B confuses percentile with mean — the mean would be much lower than P99 in most distributions. Option C is incorrect: P99 does not mean all requests took exactly that value. Option D is the precise definition: if P99 = 1,240 ms, then 99% of requests completed faster than 1,240 ms, and only the slowest 1% exceeded it. P99 and P95 are used in SLAs because they capture the experience of most users, including those on slower connections.
Key vocabulary:
• Percentile (P95, P99) — the value below which X% of observations fall
• SLA (Service Level Agreement) — a formal commitment on performance, uptime, or quality
• P50 (median) — the midpoint; 50% of requests are faster, 50% are slower
• Long tail — the small percentage of slow requests that P99 captures and the mean hides
• Worst-case latency — the response time experienced by the slowest subset of users
4 / 10
A performance engineer presents JMeter results: Mean response: 320 ms, 90th percentile: 780 ms, Error rate: 2.4%. Which interpretation is the most accurate?
A 2.4% error rate under load indicates server-side failures that must be investigated before release.
Option A ignores the error rate entirely — 2.4% errors at scale means thousands of failed transactions per hour. Option B misreads percentile: a 90th percentile of 780 ms means 90% of requests completed within 780 ms, not that 90% failed. Option C is wrong — a 2.4% error rate is never "safe to disregard" in a payment or critical-path API context; even 0.5% can be significant depending on volume. Option D is the professional interpretation: the mean is acceptable, but the error rate signals real server-side failures (HTTP 5xx, timeouts) that need root-cause analysis.
Key vocabulary:
• Mean response time — the arithmetic average response time across all sampled requests
• Error rate — the percentage of requests receiving an error response (HTTP 4xx/5xx or timeout)
• HTTP 5xx — server-side error responses (500 Internal Server Error, 502, 503, etc.)
• Root-cause analysis — investigation to identify the underlying reason for a failure or anomaly
5 / 10
A product team says "the application needs to be fast." How should the QA engineer formalise this as a measurable performance acceptance criterion?
Performance acceptance criteria must specify the endpoint, the percentile threshold, the load level, the error budget, and the test duration.
Options A, B, and D use language that cannot be tested: "fast", "acceptable", and "pass" are all subjective without numbers. No engineer can write a JMeter test or Gatling simulation against "must be fast." Option C is the professional standard: it names the specific endpoint (/api/search), the latency threshold (500 ms), the percentile (P95), the concurrency level (500 users), the error rate budget (0.5%), and the test duration (10 minutes) — every element can be directly configured in a load test tool and objectively pass/failed.
Key vocabulary:
• Performance acceptance criterion — a quantified, testable non-functional requirement
• Concurrent users — the number of simultaneous active sessions during a test run
• Error budget — the acceptable percentage or count of errors during a given period
• Test window — the duration of the performance test run (e.g. 10 minutes of sustained load)
• Non-functional requirement (NFR) — a quality attribute such as performance, security, or availability
6 / 10
Sarah (Lead QA) is reviewing a new PR for the user authentication service. The developer has included a command: `perfstat -i cpu0 -d %usr`. Which of the following best describes what this command will measure during performance testing?
perfstat is a Linux command-line tool that monitors system performance metrics. `-i cpu0` specifies CPU core 0, and `-d %usr` instructs it to display the time spent in user mode (which represents the execution of application code). This directly measures CPU usage, a key factor in performance bottlenecks. Options A, C, and D represent different aspects of system monitoring that aren't directly related to measuring application code execution.
7 / 10
Mark (Performance Engineer) is investigating slow API calls. He receives the following response from the monitoring system: 'Average latency: 150ms, 95th percentile: 350ms'. What does the 95th percentile latency value primarily indicate?
Percentiles in performance testing represent different stages of request completion. The 95th percentile means that 95% of requests completed within the specified latency window (350ms in this case). It's a robust measure of response time as it's less sensitive to outliers than the average, and gives you an idea of how long *most* users will wait.
8 / 10
David (Developer) is writing a performance report for a new feature. He wants to explain the impact of increased user concurrency on API response times. Which statement best describes how to incorporate concurrent users into a performance test?
Concurrent users are represented by virtual users in performance testing. Increasing the number of virtual users simulates a higher load on the system. However, it's crucial to maintain realistic request patterns (e.g., typical user workflows) to ensure that the test accurately reflects how the API will behave under actual concurrent usage. Option A is incorrect because it doesn't reflect real-world scenarios; option C is only for measuring peak performance, and option D ignores a critical factor.
9 / 10
Emily (QA Lead) is reviewing the results of a load test. The tool generated the following data: Response Time: 80ms, Error Rate: 1%. She needs to communicate this clearly to the development team. Which phrasing best summarizes these findings?
This phrasing provides a balanced and informative summary. '80ms' indicates acceptable response times, while '1% error rate' signifies a low level of failure, suggesting the system is generally stable under load. Framing it this way avoids alarmist language and allows for targeted investigation if needed. Options A and C are overly positive or negative, and option D is unnecessarily urgent.
10 / 10
Ben (Performance Engineer) is preparing a Slack message to report the results of a new regression test. The test revealed that the API response time for the 'search' endpoint has increased from an average of 200ms to 500ms under load. Which statement best describes how Ben should frame this issue in the message?
This response uses measured language that clearly conveys the problem without exaggerating or downplaying its significance. 'Performance degradation' is more precise than 'slower,' and specifying 'requires further investigation' indicates a proactive approach. Option A is too vague, option C suggests panic, and option D denies the issue.
This exercise, "Performance Testing Vocabulary", tests your understanding of testing & qa lab vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Testing & QA Lab exercise for?
It's designed for IT professionals and learners who want to sound natural discussing testing & qa lab topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Testing & QA Lab exercises?
Browse the full Testing & QA Lab exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.