ISTQB CT-PT Certification: Performance Testing (Complete Guide)

Black Friday, a ticket presale, month-end close at a bank, the tax filing deadline: they all have something in common. If the system can't handle the load, it doesn't matter that every feature "passes" functional testing. ISTQB CT-PT gives you a method to plan, design, run and analyze performance tests and, above all, to explain the results to decision makers. This guide explains what the syllabus covers, what the exam looks like and how to prepare.

For the full certification map and costs, see our main ISTQB certification guide.

What CT-PT is and where it sits in the ISTQB portfolio

CT-PT is ISTQB's specialist certification in performance testing. According to the syllabus, it's aimed at anyone involved in testing who wants to broaden their knowledge of performance testing, anyone who wants to start a specialist career in the field, and people in performance engineering who want a better understanding of testing.

The syllabus considers three aspects: technical (protocols, scripts, tools, monitoring), method-based (how to plan, design and analyze) and organizational (risk, stakeholder communication, lifecycle fit).

Current version

The current version is v2018, released by ISTQB on December 9, 2018. At the time of writing it remains the official version. It's available in English, with a Spanish translation.

Where it fits

You take it after ISTQB Foundation Level (CTFL 4.0). The syllabus notes that the performance content in Technical Test Analyst (CTAL-TTA) is consistent with CT-PT, which develops it in much more depth. It also relates to Mobile Application Testing (CT-MAT) and Acceptance Testing (CT-AcT), which address performance in their own contexts.

Who it's for and prerequisites

• Functional testers who want to move into non-functional testing.
• Automation engineers already using JMeter, k6, Gatling, LoadRunner or another tool who want method, not just scripts.
• Performance engineers, SREs and DevOps engineers who need a common vocabulary with QA.
• QA leads and architects who decide when, how much and how to test performance.

Exam entry requirements

The syllabus states that you must hold the Foundation Level certificate before taking the Performance Testing exam. An accredited course isn't mandatory, although it's recommended.

What you'll be able to do: business outcomes

The syllabus defines nine Business Outcomes:

Syllabus content chapter by chapter

The syllabus has five chapters with a minimum time for each. Unlike some specialist syllabi, it goes up to K4 (analyze), and many of those objectives are in chapter 4.

Chapter 1. Basic concepts (60 min)

It starts with principles: tests must align with the expectations of users, system designers and operations; be reproducible; yield understandable, comparable results; be runnable on complete or partial systems representative of production; and be affordable within the project timeframe. The three ISO 25010 performance efficiency sub-characteristics are the backbone: time behavior, resource utilization and capacity.

It then defines the types of performance testing:

• Load: increasing levels of anticipated realistic load.
• Stress: peaks at or beyond limits, or with reduced resources.
• Scalability: the ability to grow to meet future needs.
• Spike: sudden bursts and return to a steady state.
• Endurance: stability over an extended period, looking for memory leaks or exhausted connections and threads.
• Concurrency: simultaneous actions, such as many logins at once.
• Capacity: how many users or transactions the system supports while meeting objectives.

You'll also see why static testing is especially valuable for performance (reviews of requirements, database schemas, architecture and critical code), the load generation options (via the UI, crowds, the API or captured protocols) and typical failure modes: slow response at all load levels, slow response under moderate-to-heavy load, degradation over time, and poor error handling under over-limit load.

Example: a ticketing app runs fine with 200 users, but when the presale opens 20,000 arrive in a minute and it crashes. That's a capacity problem under a spike, and you catch it with a spike test, not a sustained load test.

Chapter 2. Measurement fundamentals (55 min)

No metrics, no performance test: you can't tell whether results are acceptable, you can't see trends, and you end up evaluating by opinion. The chapter covers:

• Metrics by technical environment (web, mobile, IoT, desktop, server, mainframe, database, network): response time, resource utilization, throughput of key transactions, batch processing times and more.
• Metrics for the business environment and the operational environment.
• How to select metrics, for example with the Goal-Question-Metric (GQM) approach.
• Why results are aggregated (averages, percentiles) and what you lose by doing so.
• Metric sources: performance test tools, monitoring tools and log analysis tools.
• Typical results of a performance test.

Example: "the page loads in 2 seconds" says nothing on its own. "The 95th percentile checkout response time is under 2 seconds with 1,000 concurrent users at peak, with database CPU below 75%" is a useful metric.

Chapter 3. Performance across the lifecycle (195 min)

Here you connect performance testing to the Foundation Level test process: planning (environments, data, tools and people), monitoring and control, analysis, modular design, implementation (including resetting environment and data), execution, and completion with a report for stakeholders.

Then you review performance risks by architecture: single-computer, multi-tier, distributed, virtualized, dynamic/cloud-based, client-server, mobile, embedded real-time and mainframe systems.

The chapter's two K4 objectives are to analyze a product's performance risks across the lifecycle (identify, assess, mitigate and manage, with business and technical stakeholders, starting early) and to determine the appropriate performance testing activities for each phase in sequential models (from concept to acceptance), iterative models with continuous integration (on-demand environments, a subset of tests for CI, stories with non-functional criteria) and supplier/COTS models.

Example: in a Scrum team, each critical story includes a performance criterion; the CI pipeline runs a short performance regression test on every build; and before release a specialist team runs the full load test in a production-representative environment.

Chapter 4. Performance testing tasks (475 min)

The heart of the certification: more than half the study time and 20 of the 40 questions. It has four blocks:

Planning (K4). Derive performance test objectives (business and technical) from stakeholder input; outline a performance test plan with objective, system overview, test types, acceptance criteria, test data, system configuration, environment, tools, profiles, relevant metrics and risks; and create a presentation explaining the rationale to business-focused and technology-focused stakeholders.

Analysis, design and implementation.

• Typical protocols: database (ODBC, JDBC), web (HTTP, HTTPS), web services (SOAP, REST), plus network, mobile, remote access and SOA protocols.
• Transactions and the role of think time: transaction response time plus think time equals elapsed time.
• Operational profiles (K4): identify data (personas and roles, tasks, estimated users per role and task), gather it (interviews, specifications, usage data from similar or current systems, observation) and build profiles top-down. Also for batch processing and systems of systems.
• Load profiles (K4) derived from operational profiles: ramp-ups, ramp-downs, steps and predefined distributions.
• Throughput and concurrency (K4), including throughput = virtual users / (processing time + think time).
• Basic script structure, implementing scripts consistent with the plan and load profiles (K3), and preparing for execution.

Execution. Generate load according to the profile, monitor the whole environment, distinguish steady and transient states, handle script failures and verify with functional scripts running in parallel.

Analysis and reporting (K4). Check virtual user status first, then response times (minimum, maximum, average and percentiles), transactions per second, failures and resource utilization; report with an executive summary, results, logs and recommendations.

Throughput example: with 100 virtual users, 1 second of processing time and 4 seconds of think time, throughput is 100 / (1 + 4) = 20 transactions per second. If processing time rises to 6 seconds under load, throughput drops to 10 per second with the same number of users. That's why the syllabus insists on not defining load only by "number of users".

Chapter 5. Tools (90 min)

• Tool support: load generators, load management console and monitoring tools.
• Tool suitability (K4) for a given scenario: compatibility (protocols, technologies, environment), scalability (how much load it can generate and with what infrastructure), understandability, and monitoring (whether it's sufficient, can be supplemented and correlated with transactions).

The syllabus doesn't teach a specific tool; it gives you the criteria to choose one and use it well.

Download the official syllabus

Here's the English syllabus. ISTQB also publishes a Spanish translation (v2018), available from the official certification page:

The CT-PT exam

Verified structure

Source: ISTQB Exam Structure and Rules Tables v1.18 (May 2026) and the iSQI exam page. Note: the detailed section of that same ISTQB document says "60 minutes for 40 questions", so confirm the duration when you book. According to the published distribution, chapter 4 contributes 20 questions, chapter 3 contributes 7, chapter 1 contributes 6, chapter 2 contributes 4 and chapter 5 contributes 3.

Exam formats

• Online with remote proctoring (iSQI FLEX), 24/7: book at least 2 hours ahead. You need a webcam, a microphone, a second camera (your phone) and a government-issued ID.
• Pearson VUE: at a test center or online with OnVUE.
• On-site at your company for groups of 6 or more: Cool Testers brings a proctor.

Paper-based exams are no longer offered. At the time of writing, iSQI offers CT-PT in several languages, including English and Spanish. The certification has the same value in any language; some companies with US projects may prefer the English exam, but that's their decision.

Where to buy it

• Directly at iSQI.org, our partner and official exam provider, with a 20% coupon off the price on their site for the first attempt for Cool Testers students. Recommended if you're paying yourself.
• Through Cool Testers (certification exam, 1 or 2 attempts) if your company pays or you need an invoice. You have 1 year to take it. Contact us to confirm availability.

Costs in your currency: main ISTQB certification guide.

How to prepare for CT-PT

1. Give chapter 4 half your study time. It's half the exam and holds almost all the K4 objectives.
2. Build a real performance test plan for a system you know, with every section the syllabus lists (objectives, profiles, acceptance criteria, metrics, risks).
3. Practice operational and load profiles. Define 3 user types with their tasks and hourly volumes, and turn them into a load profile with ramp-up, steady state and ramp-down.
4. Do throughput calculations by hand with different values for users, processing time and think time.
5. Run a small test with a tool (JMeter, for example) against a practice environment: seeing a real report with percentiles and errors makes section 4.4 click. If you're interested in APIs, our Postman course helps you understand the REST services you'll later put under load.
6. Review the test types (load, stress, scalability, spike, endurance, concurrency, capacity) with your own example for each.
7. Take the official sample exam and review each rationale, especially for analysis questions.

If your company needs to train its team in performance testing, request a quote or message us on WhatsApp.

Benefits and career paths

• You specialize in an area with few strong profiles. Many people can record a script; few can derive objectives, build realistic profiles and explain results to the business.
• You speak the language of architecture and operations. Throughput, concurrency, percentiles and resource utilization underpin any conversation with SRE or DevOps.
• You help avoid costly incidents. Performance failures tend to show up at the worst moment: campaigns, closings, peak seasons.
• It complements automation. CT-PT gives you the method; tools like JMeter give you execution.
• Roles where it adds value: performance tester, performance engineer, non-functional QA, SRE with a testing focus, technical QA lead.

We don't quote salary figures because they vary a lot by country and company.

Related certifications and next steps

Frequently asked questions

What is the ISTQB CT-PT certification?

It's ISTQB's specialist certification in performance testing. It covers concepts and test types, metrics, risks by architecture, lifecycle activities, planning, operational and load profiles, scripts, execution, results analysis and tool selection.

How many questions are on the CT-PT exam and how long is it?

40 questions, and you pass with 26 (65%). The official ISTQB table and the iSQI exam page list 90 minutes, or 113 if it isn't in your native language. Confirm the duration when you book.

Do I need Foundation Level to take CT-PT?

Yes. The syllabus states that you must hold the Foundation Level certificate before taking the exam.

Does the Cool Testers JMeter course prepare me for the CT-PT exam?

No. The JMeter course builds the hands-on skill of creating and running performance tests, but it doesn't follow the ISTQB syllabus or prepare you for the exam. It's a good complement, especially for chapters 4 and 5.

Can I take CT-PT in Spanish?

Yes. At the time of writing, iSQI offers the CT-PT exam in Spanish as well as other languages, including English. There's also a Spanish translation of the syllabus.

Do I need to know how to code for CT-PT?

Not for the exam: it covers concepts, planning, analysis and tool selection. Understanding protocols such as HTTP and REST and having some experience with a load testing tool does help.

What's the difference between load testing and stress testing?

Load testing evaluates the system under increasing levels of anticipated realistic load. Stress testing pushes it to peaks at or beyond its limits, or with reduced resources, to see how it behaves and recovers.