ISTQB CT-PT common mistakes
ISTQB CT-PT · Understand the traps and how to avoid them.
Treating performance testing as functional testing with a stopwatch: writing test cases that verify a response is 'correct' rather than measuring whether it meets a stated performance requirement within a defined workload.
Candidates come from a functional background where pass/fail is binary and expected results are exact; they carry that mindset into performance work and miss that the objective is comparing measured values (response time, throughput, resource use) against defined targets under defined load.
What to do instead
For each scenario, state the performance objective explicitly (e.g., 95th percentile response time under 2 seconds at 500 concurrent users) and describe the pass criterion as a comparison against a baseline or requirement, not an expected output value. Practise rewriting functional test cases into performance objectives until it is automatic.
Confusing load, stress, spike, endurance/soak, and scalability testing, and answering questions as if any test that applies load is a 'stress test'.
Everyday language uses 'stress' loosely for anything demanding, and the test types overlap in tooling, so candidates skim the definitions. Exam items, however, hinge on the purpose (finding the breaking point vs. verifying behaviour at expected load vs. detecting degradation over time) and the load profile (constant, ramping, sudden, sustained).
What to do instead
Build a one-line purpose-and-load-profile card for each type: load test = expected peak load, verify requirements; stress test = beyond limits, find failure point and recovery; spike test = abrupt load change; endurance test = sustained moderate load over hours, watch for memory leaks and resource exhaustion; scalability test = increasing load or resources to see whether throughput scales. Match the scenario's stated intent to the purpose, not to the word 'load'.
Mixing up response time, throughput, and resource utilisation, or using 'response time' to mean the whole transaction including think time and network, when the question asks about server-side processing.
These metrics are all 'speed' in casual speech, and end-to-end time is what a user actually experiences, so candidates answer from intuition rather than from the definitions. Many questions deliberately supply several numbers and test which metric answers the question.
What to do instead
Memorise the distinctions: response time is elapsed time from request to complete response (and can be decomposed into network, queueing, and processing components); throughput is work completed per unit time (transactions per second, requests per second); utilisation is the fraction of a resource's capacity in use. When a question names a metric, translate it into its unit before choosing an answer, and check whether think time or network latency is stated to be included or excluded.
Interpreting averages as the whole story and ignoring percentiles and distribution, e.g., concluding a system meets its target because the mean response time is 1.5 seconds when the 95th percentile is 6 seconds.
Averages are familiar and easy to compute, and reports often lead with them. Candidates forget that response times are typically skewed, so a mean hides the tail that real users experience, and exam questions are built precisely around that gap.
What to do instead
Default to percentiles (median, 90th, 95th, 99th) plus maximum and error rate when evaluating a result. Practise reading a small dataset and computing or estimating the 95th percentile to see how far it can sit from the mean. If a question gives only an average, treat the conclusion as unsupported rather than correct.
Blaming the application for slow response times without considering the test environment, test data, network, or monitoring overhead, and skipping the step of correlating client-side results with server-side resource metrics.
The client-side tool reports what the user saw, so candidates jump from 'slow' to 'the code is slow'. They underestimate how often load generators, insufficient test data, unrepresentative environments, or unmonitored bottlenecks (CPU, memory, disk I/O, connection pools, database locks) explain the result.
What to do instead
Adopt a fixed analysis sequence: validate the workload model and environment first, then check the load generator is not the bottleneck, then correlate response time with server resource metrics and error logs at the same timestamps. When asked to interpret a result, name the evidence you would need before attributing the cause, and reject answers that assert a root cause without that evidence.
Designing a workload model without realistic user profiles, arrival patterns, think times, or representative data volumes, e.g., having all virtual users execute the same transaction in lockstep at maximum speed.
It is far easier to script a loop that hammers one endpoint, and candidates focus on getting the tool to run rather than on whether the load resembles production. Lockstep behaviour also produces artificially synchronised peaks that misrepresent real traffic.
What to do instead
Before scripting, define the workload model: the mix of user types and business transactions with their proportions, arrival rate or concurrency, think times and pacing, ramp-up profile, and data variety and volume. Ensure test data is representative and large enough not to be exhausted. In exam scenarios, ask whether the described load matches production usage patterns; if it does not, the scenario is flawed regardless of the tool.
Skipping or rushing performance test planning and analysis: jumping straight to executing a script, then reporting raw numbers with no baseline, no acceptance criteria, and no interpretation.
Execution feels like the productive part, so planning (objectives, acceptance criteria, workload model, environment, schedule) and analysis (baseline comparison, trend, root-cause input) get compressed. Candidates then cannot answer questions about what should happen before or after execution.
What to do instead
Learn the activity sequence and what each phase produces: define objectives and acceptance criteria, plan and design, build the environment and scripts, execute (including baselining and monitoring), analyse and report, then feed findings back. For any 'what should the tester do next' question, locate the current phase and choose the action that belongs to it, not the most technical-sounding one.
Assuming a tool records everything needed by default, or that a recorded script is a finished test: accepting default settings, leaving hard-coded values, and not parameterising, correlating dynamic data, or validating the script.
Modern tools make recording trivial, which creates the impression that the work is done. Dynamic session IDs, tokens, and timestamps break replay, and default logging and think-time settings distort results. Candidates who have only seen demos do not anticipate this.
What to do instead
Treat a recorded script as a draft. Always parameterise input data, correlate server-issued dynamic values, set think times and pacing deliberately, add validation of responses, and run a single-user baseline to confirm the script is correct before applying load. In questions about tool use, prefer answers that mention verification, parameterisation, and correlation over answers that rely on defaults.
Ignoring organisational and project factors: assuming performance testing can start at the end of the project, that the tool choice is purely technical, or that a single specialist can own all performance work without skills, training, and stakeholder agreement.
Performance testing is often taught as a tool-and-metrics subject, so candidates underweight early involvement, environment availability, cost and licensing, skills development, and communication of results to non-technical stakeholders. Exam items on roles, risk, and process then feel unfamiliar.
What to do instead
Study the organisational side as its own topic: when performance activities should begin (early, aligned with the lifecycle and risk), how tool selection weighs cost, licensing, protocol support, skills, and integration, what training and coaching are needed, and how results are communicated to technical and business audiences. For process questions, prefer answers that integrate performance work into the lifecycle and involve stakeholders over answers that treat it as a final gate.
Misreading the question's scope word: answering about the load generator when the question asks about the system under test, or about monitoring when it asks about measurement, and choosing a technically true statement that does not answer what was asked.
Performance questions are dense with nouns (workload, load generator, system under test, monitor, metric) and many options are individually true. Under time pressure, candidates match on a familiar keyword instead of identifying the subject and the verb of the question.
What to do instead
Before reading the options, restate the question in one sentence naming the subject (what is being measured or done) and the required action. Then eliminate options that are true but off-subject. If two options remain, prefer the one that uses the exact terminology of the syllabus for that concept rather than a looser synonym.