Performance testing course: from certified QA to ISTQB Performance Tester

Understand test types and metrics, place performance risks in the lifecycle, then write requirements and plan a campaign (CT-PT syllabus, chapters 1 to 4). Each session lasts 2 h.

Week 1 — Principles and test types

• S01 — Performance efficiency: response time, resource utilization, capacity
• S02 — Test types: load, stress, scalability, spike, endurance, concurrency, capacity
• S03 — Generating load: through the UI, through the API, through the protocol
• S04 — Common performance failures and their causes
• S05 — Workshop: choose the right test type for five real situations

Week 2 — Measuring

• S06 — Metrics: response time, throughput, error rate, concurrent users, resources
• S07 — Percentiles p50, p95, p99 and aggregation: the pitfalls of the average
• S08 — Metric sources: load tool, APM, logs, system
• S09 — Typical performance test results and how to read a report
• S10 — Hands-on: a first k6 script and reading the metrics

Week 3 — Lifecycle and risks

• S11 — Performance testing activities, from planning to closure
• S12 — Risks by architecture: monolith, microservices, cloud, mobile, IoT
• S13 — Risks across the development lifecycle: test early, test in production
• S14 — Performance requirements, SLOs and measurable acceptance criteria
• S15 — Workshop: performance risk analysis of a demo application

Week 4 — Planning

• S16 — Performance test plan: objectives, scope, environment, data, criteria
• S17 — Operational profiles and load profiles
• S18 — Throughput and concurrency: Little’s law, think time, pacing
• S19 — A representative test environment and test data
• S20 — Competency gate P1: graded test plan + CT-PT syllabus quiz (ch. 1 to 4)

Choose a tool, write k6, JMeter and Locust scripts, test APIs and the browser, then industrialize in continuous integration (CT-PT syllabus, chapters 4 and 5). Each session lasts 2 h.

Week 5 — k6

• S21 — Choosing a tool: protocols, language, cost, CI, distributed execution (k6, JMeter, Locust, Gatling)
• S22 — k6: JavaScript scripts, virtual users, iterations, checks
• S23 — k6: scenarios and executors (ramp-up, constant arrival rate)
• S24 — k6: thresholds as acceptance criteria
• S25 — k6: test data, parameterization, modules

Week 6 — JMeter

• S26 — JMeter: test plan, thread groups, samplers
• S27 — Correlation (extractors) and parameterization (CSV files)
• S28 — Assertions, timers, controllers
• S29 — Command-line execution and HTML report
• S30 — Hands-on: the same scenario in k6 and in JMeter, compared

Week 7 — Locust, APIs and the browser

• S31 — Locust: Python tasks, users, distributed execution
• S32 — REST and GraphQL API performance
• S33 — Authentication, tokens and sessions in scripts
• S34 — Browser-level tests with k6 browser
• S35 — Record a user journey (k6 Studio, JMeter proxy), then clean up the script

Week 8 — Industrializing

• S36 — Continuous integration (GitHub Actions): a quick performance test on every commit
• S37 — Distributed execution and load generation from the cloud
• S38 — Storing results and comparing versions (baseline)
• S39 — Maintaining scripts over time
• S40 — Competency gate P2: k6 + JMeter tooled campaign on an API, thresholds in CI

Monitor a campaign, find bottlenecks, measure browser-side performance, write the report, then complete the Capstone. Each session lasts 2 h.

Week 9 — Monitoring

• S41 — Observability: metrics, logs, traces (OpenTelemetry)
• S42 — Prometheus: collection and basic queries
• S43 — Grafana: a load test dashboard
• S44 — Linking load to server resources
• S45 — Hands-on: a complete campaign dashboard

Week 10 — Finding bottlenecks

• S46 — Analysis method: from symptom to cause
• S47 — Database: slow queries, indexes, connection pool
• S48 — Cache, network and CDN
• S49 — Code and memory: leaks, garbage collection, profiling
• S50 — Workshop: diagnosing a deliberately slow application

Week 11 — Browser-side performance

• S51 — Loading, rendering and client-side JavaScript
• S52 — Core Web Vitals: LCP (≤ 2.5 s), INP (≤ 200 ms), CLS (≤ 0.1) and their thresholds
• S53 — Lighthouse and Lighthouse CI
• S54 — Lab data and field data (CrUX, RUM)
• S55 — Testing in production with care: synthetic monitoring, progressive rollout

Week 12 — Report and Capstone

• S56 — Analyzing results and writing the performance report
• S57 — Presenting to technical teams, the business and management
• S58 — Recommendations and optimization plan
• S59 — Capstone preparation
• S60 — Competency gate P3: complete performance report and presentation

Two days of intensive preparation for the official exam: structured syllabus review by area, exercises, mock exams with commented answers, strategy and time management.

You receive the application provided by ADC and deliver a complete performance campaign: test plan, k6 and JMeter scripts, execution, Grafana dashboard, diagnosis, report and defense. The defense, in front of a three-member panel that includes an external performance professional, focuses on justifying your choices: why this load profile, which thresholds, which cause behind this bottleneck, which recommendation and why.

• Assessment rule: a simple campaign that you understand and can defend beats a pile of tools you have not mastered.

Full-time follows the same structure as our 399 h QA Automation & AI Tester path: 371 h of virtual-classroom training, 14 h of individual support and assessments, 14 h of ISTQB CT-PT exam preparation. Sessions S01 to S60 above are covered in greater depth, with supervised workshops every afternoon.

A seven-hour day

• 9:00 – 10:30 am — Concepts and demonstration
• 10:45 am – 12:30 pm — Guided workshop
• 1:30 – 3:30 pm — Independent workshop on a load campaign
• 3:45 – 5:00 pm — Review, correction, wrap-up

Each block ends with, or contributes to, a competency gate; same ADC certificates, same Capstone and same ISTQB CT-PT exam as the evening classes.