ISTQB Specialist (CT-PT) Mock Exam #1 — Questions & Answers

Incorrect - Time Behavior is one of the three sub-characteristics. It covers response times, processing times and throughput rates measured against requirements.

Incorrect — Capacity is one of the three. It is the maximum limit of a parameter, such as the number of concurrent users or transactions, that the system can sustain.

Incorrect — Resource Utilization is one of the three. It covers the amounts and types of resources (CPU, memory, disk, network) consumed while performing a function.

Incorrect. Scalability testing determines whether the system can grow to meet future load, usually by adding resources or increasing load in stages. Nothing is being scaled here; the load is held constant and only elapsed time varies.

Incorrect. Stress testing deliberately pushes load beyond the anticipated maximum to find the point at which the system fails and to observe how gracefully it does so. Here the load stays at normal levels.

Incorrect. Spike testing applies sudden, short bursts of load and then removes them, checking recovery. The load in this scenario is deliberately constant.

Incorrect. A soak, or endurance, test holds a representative load for a long period to expose gradual degradation; a few minutes of burst is the opposite profile.

Incorrect. Stress testing raises load steadily beyond the expected maximum to locate the failure point; the portal's concern is a short burst and the recovery that follows it.

Incorrect. Capacity testing establishes how many users or transactions can be handled while the performance objectives are still met - a sustained question, not a burst-and-recover one.

Incorrect. Including rendering time is a genuine advantage of UI-driven load, but each simulated user then needs a full client instance, which is exactly what the stated hardware budget rules out for hundreds of users.

Incorrect. Crowd-based generation uses large numbers of real users in distributed locations; it is poorly repeatable and controllable, and it is impractical for an internal trading system handling real positions.

Incorrect. The API route presupposes a documented interface, and the vendor has refused to release the interface specifications.

Incorrect. This executes the system under load and is therefore dynamic performance testing, whatever the number of users or the acceptance limits applied to the result.

Incorrect. Profiling requires the code to execute, which makes it a dynamic testing type even though it operates at unit level.

Incorrect. This failure mode shows slow responses even immediately after a restart with one user active. The application is described as responding acceptably when freshly restarted, which rules the mode out.

Incorrect. This mode concerns ungraceful behaviour once the capacity limit is reached, such as raw error pages or lost transactions. The reported load is stable and well inside capacity, and the drift is in elapsed time.

Incorrect. Saturation failures track the load level: performance is fine when few users are active and degrades when many are. Here the load is stable and time is the variable.

Incorrect. Accepting whatever a tool reports by default is exactly the undirected collection that GQM is intended to prevent, and familiarity is not a criterion for relevance.

Incorrect. TMMi assesses the maturity of a test organisation's processes; it says nothing about which metrics an individual performance test should collect.

Incorrect. FMEA identifies failure modes and their effects as part of risk analysis; it is not the approach the syllabus names for selecting performance metrics.

Incorrect. Thread pool occupancy is resource utilisation and belongs to the technical environment category.

Incorrect. Restore-from-backup timing is an operational environment metric, along with start-up, shutdown, resumption and alerting.

Incorrect. Network latency is a technical environment metric describing infrastructure behaviour, and measuring it at peak load does not move it into the business category.

Incorrect. The traced figures carry overhead that will not be present in production, so publishing them as the real values would overstate the problem and send the team tuning code that is not actually slow.

Incorrect. A correlation defect shows up as errors and failed transactions in specific steps, not as a uniform slowdown that appears and disappears with the tracing setting.

Incorrect. The load was identical in both runs and only the instrumentation changed, so the evidence points at the measurement apparatus rather than at capacity. Buying hardware here would address a symptom created by the tester.

Incorrect. Monitoring tools report resource consumption, and contention frequently shows as low CPU with poor response, so utilisation figures alone will not confirm a deadlock.

Incorrect. The load tool sees only what the client sees. A deadlock that was retried successfully leaves no trace in its transaction report beyond a slightly longer time.

Incorrect. Recomputing a percentile from the same client-side samples adds no new information about what happened inside the database; it only re-expresses measurements the tool already produced.

Incorrect. Self-scaling and the configuration mistakes that go with it define the dynamic, cloud-based category. A handset does not provision instances, so this cannot be the source of variation on the device side.

Incorrect. Deadlines whose violation is a failure rather than a slowdown characterise the embedded real-time category, which the syllabus keeps separate from mobile applications.

Incorrect. That combination describes the mainframe category: a historically predictable system whose risk now comes from the modern access paths placed in front of it, not from a mobile device.

Incorrect. Cloud platforms publish extensive utilisation and instance-level telemetry. The real difficulty is interpreting metrics gathered from a set of instances that changes during the run, which is a different problem from having no metrics.

Incorrect. Headroom does not remove inefficient queries, serialised components or badly set scaling thresholds, and the syllabus treats the cloud category as adding risk rather than removing the need to test.

Incorrect. Cloud hosting makes generating load from several points of presence easier rather than harder, and in any case the number of load injection points is not what defines this risk category.

Incorrect. Controlled laboratory conditions are precisely the problem: the benchmark reflects the vendor's hardware, configuration and data, so it says nothing about the insurer's own profiles and volumes. The syllabus puts the responsibility on the acquirer.

Incorrect. The syllabus describes no mandatory equal split, and running the same suite in two different environments would produce two sets of figures without answering the acquirer's question about its own deployment.

Incorrect. No market certification covers the acquirer's configuration, data volumes and integrations, and configuration does far more than select features - it is exactly where COTS performance problems normally appear.

Incorrect. Recording a result is monitoring, not control. Control is the action taken in response to what monitoring reveals.

Incorrect. Re-cutting the same data differently changes the presentation, not the system, and is not a control measure in the sense the syllabus uses.

Incorrect. Gathering operational profile data is a test analysis activity performed before design, not a corrective control measure.

Incorrect. The load profile comes from the operational profiles rather than from the size of the increment, and a baseline is established once and then reused; small increments in fact make it easier to isolate which change caused a regression.

Incorrect. One of the five principles of performance testing is that it can be conducted on a complete or a partial system, so measurements from early increments are usable and waiting for feature-completeness only concentrates the risk at the end.

Incorrect. Production monitoring is a valuable additional source of data in an Agile context, but the syllabus presents it as a supplement to testing during the iterations rather than a replacement, and a defect found only in production is the most expensive one to fix.

Incorrect. A customer whose request failed was not served within the threshold either, so excluding those requests understates the impact. The syllabus also warns that failed transactions distort results, because they usually complete faster and inflate apparent throughput.

Incorrect. A relative improvement measured against an estimate says nothing about whether the agreed requirement is met, and 2.4% still sits well above the 1% ceiling. The statement also leaves the failed transactions out of the count entirely.

Incorrect. Performance testing often does lack a clear oracle, but here an explicit numeric requirement exists and that requirement is the oracle. The syllabus asks for residual risk to be expressed quantitatively wherever the figures allow it.

Incorrect. 44% CPU and 55% pool occupancy are comfortable figures and neither is trending towards a limit, so neither can explain a queue that grows steadily. Picking the largest number among several low numbers is not analysis.

Incorrect. Uneven distribution would appear as differing utilisation between web instances, but every instance is reported healthy at 38%. It also would not explain why the batch path for the same operation returns in 0.9 seconds.

Incorrect. A saturated processor would show in its own utilisation figures, and the mainframe's CPU is within its normal envelope while the batch window is unchanged. Upgrading it would spend a large budget without touching the actual constraint.

Incorrect. The syllabus specifically advises differentiating communication between business-focused and technology-focused stakeholders; one consolidated table buries the figure each audience actually needs.

Incorrect. Throughput and resource utilisation targets are routinely agreed in advance and appear as acceptance criteria in the Performance Test Plan.

Incorrect. Users experience response time directly and have no visibility of resource utilisation, so this mapping reverses the syllabus position; capacity costs reach the user only indirectly, through price.

Incorrect. Duplicating rows inflates volume while collapsing key cardinality and skew, so the result is less representative than the masked extract it was built from; the caveat the syllabus raises is about characteristics rather than size.

Incorrect. Data protection obligations cover personal data in general, not only direct identifiers, and substituting values does not preserve distribution — the characteristics that drive index selectivity are exactly what masking tends to destroy.

Incorrect. The obligation follows the personal data itself rather than the location of the server, so an internally hosted test environment is not exempt from it.

Incorrect. One of the five principles is that performance testing may be conducted on a partial system, and the syllabus treats a reduced environment as a known limitation to be reported, not a reason to postpone the test.

Incorrect. Linear scaling is the assumption the syllabus warns against: caches, connection pools and shared resources do not scale proportionally, so doubling the measured figures is unsound.

Incorrect. The syllabus warns that raw figures on their own are frequently misleading, so publishing them without interpretation is a recognised pitfall rather than a safeguard.

Incorrect. Ethernet operates at layer 2, far below the range the syllabus identifies as relevant for scripting load.

Incorrect in this context. TCP and UDP are transport-layer (layer 4) protocols; the syllabus point is that scripting is normally done at layers 5 to 7, above them.

Incorrect. Think time models the human pause between interactions, not server processing. Server processing and network latency both sit inside the transaction response time.

Incorrect. The two differ precisely by the think time, which is why reducing think time in a script raises the load generated without adding any virtual users.

Incorrect. This makes transaction response time the largest of the three, which cannot be right - response time is a component of elapsed time, not the sum containing it.

Incorrect. Developer intuition about criticality is not a substitute for data on how the system is actually used, which is what interviews and log analysis provide.

Incorrect. One recorded session cannot represent a mixed user population, and scaling it uniformly ignores the different behaviours of different roles, however carefully the total is tuned.

Incorrect. The syllabus specifically recommends a top-down construction; starting from queries is grounded in data but loses the business context that determines realistic transaction mixes.

Incorrect. The syllabus points to layers 5 to 7 as the appropriate range for scripting, and a verbatim transport-layer capture would be harder to parameterise, leaving the dynamic values just as hard-coded as before.

Incorrect. A saturated generator distorts timings and drops requests, but it does not produce systematic authorisation failures that appear as soon as a second user joins.

Incorrect. Think time governs how much load a given population generates; lengthening it does not repair a request that carries a session identifier belonging to another user.

Incorrect. Scripts are not partitioned by OSI layer; the layering concerns which protocol the script drives, not its internal structure.

Incorrect. Recording and reporting are activities of the tooling and of the test process; they are not sections inside an individual script.

Incorrect. Timing the whole script as one transaction removes the ability to attribute a slowdown to a specific business operation, which is exactly why individual timers are placed around the transactions of interest.

Incorrect. Surviving ramp-up says nothing about behaviour over a sustained period, which is precisely why endurance testing exists and why the steady state is the usual object of analysis.

Incorrect. Diluting the transient into a long-run average destroys the very behaviour a spike or mass log-on test is designed to expose, rather than making the distinction unnecessary.

Incorrect. Discarding transient data as a rule would make it impossible to evaluate the very scenarios — spike tests and mass log-on — in which the transient behaviour is itself the requirement under test.

Incorrect. Scripts are test artefacts maintained and versioned separately; the syllabus does not list them as a section of the report, and reproducibility is served by the test logs.

Incorrect. Formal sign-off is a governance artefact of the release process, not a section of the performance test report as the syllabus describes it.

Incorrect. This divides the virtual users by the think time alone (600 / 10). The processing time is part of the iteration cycle and belongs in the denominator.

Incorrect. This divides the virtual users by the transaction response time alone (600 / 2) and omits the think time, which greatly overstates the load actually generated.

Incorrect. This assumes every virtual user completes a transaction every second, which would hold only if the iteration cycle time were exactly one second.

Incorrect. This equates the number of virtual users to the per-minute throughput figure directly, which only holds if each user completes exactly one transaction per minute - here the cycle is 30 seconds, not 60.

Incorrect. This uses only the 3-second processing time as the cycle (2 x 3 = 6) and drops the think time, which understates the required population tenfold.

Incorrect. This multiplies the per-minute target by the 30-second cycle without first converting the target to a per-second rate, inflating the answer by a factor of 60.

Incorrect. An instantaneous start makes the whole ramp period unobservable and creates a mass log-on transient the profile does not describe, while dropping the background sessions removes load that competes for the same resources.

Incorrect. Without a hold at the peak the system never reaches steady state, so a single reading at 220 reflects a transient and is not comparable with a two-hour requirement; it also drops the 100 background sessions.

Incorrect. Removing think time changes the throughput generated and breaks the relationship between population and load, and a fifteen-minute run cannot demonstrate two hours of sustained peak.

Incorrect. Response time matters most to users, but reading it before the validity of the run has been established risks passing or failing the system on figures drawn from a broken run.

Incorrect. Response codes are examined last in the recommended order, and virtual user status already answers the question of whether the users completed their work, at a higher and more direct level.

Incorrect. Network throughput comes later in the recommended order, after virtual user status, response times, transactions per second, failures and hits per second.

Incorrect. The criterion is stated at the 90th percentile, and 90% of transactions did complete within 2.00 s. Substituting a stricter percentile than the one agreed rewrites the requirement instead of evaluating it.

Incorrect. The average and the 90th percentile both fall inside the dense first mode, which is exactly why they say nothing about the second cluster. Reporting them alone is the misuse of aggregates the syllabus warns against.

Incorrect. Ordinary scatter produces a single mode with thinning tails, not a second cluster holding 800 transactions, and trimming 8% of the population as outliers would delete the finding instead of explaining it.

Incorrect. CPU utilisation never leaves the 41–46% band across the whole run. Saturation would show utilisation climbing towards its ceiling as response times worsen, and it would not depend on elapsed time at a constant load.

Incorrect. Throughput is flat at approximately 120 transactions per second for the whole 12 hours, and the profile was already rate-driven, which is what makes elapsed time the only variable that changed.

Incorrect. The probe effect imposes a broadly constant overhead rather than one that worsens steadily over twelve hours, and switching monitoring off would remove the very evidence needed to characterise the defect.

Incorrect. The lock waits come from many sessions targeting one row; faster storage shortens each write slightly but leaves the serialisation created by the shared record in place.

Incorrect. Production caches serve a wide working set at a far lower hit rate; a cache returning one record to 400 users is not production behaviour, so the figure flatters the system.

Incorrect. Linear extrapolation of CPU is unsound — the syllabus notes performance is a non-linear function of the environment — and in any case 51% measured is not evidence of saturation.

Incorrect. Reporting the generator's limit as the system's capacity would understate the true capacity and could trigger an unnecessary hardware purchase; the figure the business asked for still has to be a valid one.

Incorrect. Throughput tracks the population only while the system keeps up with it; the syllabus is explicit that the number of users does not determine load, throughput does. The rising response time shows the iterations are still running, only more slowly.

Incorrect. The seven-second guideline is a usability expectation rather than a validity criterion for a measurement, and discarding the data would throw away the capacity finding the run produced.

Incorrect. Removing think time raises the rate offered to the system, but the system is already returning its maximum completion rate; the ceiling is its service capacity. Response time climbing to 7.5 s while throughput is flat shows the constraint lies downstream of the generator.

Incorrect. A correlation defect yields errors or wrong content and shows up as failed transactions; here both script sets complete successfully and simply measure different boundaries of the same operation.

Incorrect. Averaging measurements of two different things produces a number that describes neither. GUI drivers are resource-hungry and must be monitored, but that is something to check, not something to compensate for with arithmetic.

Incorrect. Being closer to the server makes the protocol figure narrower, not more accurate; reporting 1.1 s would tell stakeholders the dashboard is six times faster than users find it.

Incorrect. Test management tooling is general test infrastructure and is not among the three performance-specific tool categories.

Incorrect. Static review of performance-critical code is a static testing activity, but such a tool is not one of the three categories of performance test tooling named in chapter 5.

Incorrect. The syllabus asks specifically whether a tool's monitoring capability can be supplemented by other tools, which implies that it normally can; and monitoring is not the factor it calls underestimated.

Incorrect. Compatibility with protocols, platforms and external interfaces such as CI is a genuine selection criterion, but the syllabus does not describe it as the underestimated one - protocol support is usually the first thing a team checks.

Incorrect. Scalability covers virtual user counts, licensing models and generator configuration and it matters a great deal, but it is not the factor the syllabus singles out as underestimated.

Incorrect. Understandability does matter, but a tool that cannot drive two of the three applications leaves the largest performance risks in the portfolio untested. A weakness that training can close should not outweigh a capability the tool simply does not have.

Incorrect. Timing a handful of sessions by hand produces single-user measurements and generates no concurrent load, so extrapolating them to peak says nothing about how those two applications behave under load. The compatibility gap remains.

Incorrect. Two toolsets mean two licence costs and two skill sets, and results produced by different engines are hard to consolidate or correlate — which weakens monitoring and reporting rather than strengthening them.