🗓️ 14-Day Performance Tester Prep Plan

// STUDY

• Performance test taxonomy: load, stress, spike, soak, volume, and capacity tests — what question each answers, when to run each in a release cycle, and how to explain the difference to a stakeholder who just says 'run a load test'
• Non-functional requirements: how to define, document, and validate response time SLAs — the difference between SLA (contractual), SLO (internal target), and SLI (the measured metric), and why confusing them causes reporting failures
• Why averages lie: p50, p75, p95, and p99 percentile metrics, the long tail of user experience, and how to explain to a product manager why a 300 ms average response time coexists with a 12 s p99
• Baseline testing: measuring the system's current performance profile under zero synthetic load so you have a meaningful comparison point before any load test begins

// PRACTISE

• Read the Performance Tester role page and note the 3 topic areas where your vocabulary is least precise — these become your re-study targets for Days 12–14
• Given the NFR '1,000 concurrent users, p95 response time < 2 s, error rate < 0.5%, sustained for 10 minutes', write a one-paragraph test approach: test type, ramp-up shape, hold duration, and pass/fail criteria
• Write a 2-minute verbal explanation of why a reported average response time of 300 ms is insufficient information for a go/no-go decision — what additional percentiles and error rates you would require, and why

// STUDY

• JMeter: thread groups, ramp-up periods, HTTP Sampler configuration, CSV Data Set Config for parameterised user data, Response Assertion for status and body, Listeners (Aggregate Report, Summary Report) for interpreting raw results
• k6: VU lifecycle stages (init, setup, default, teardown), stages config for ramp-up/hold/ramp-down shapes, thresholds as machine-readable pass/fail criteria, checks for per-request assertions, and the k6 cloud results dashboard
• Correlation: extracting dynamic values (CSRF tokens, session IDs, auth tokens) using JMeter's JSON Path Extractor or Regular Expression Extractor, or k6's response.json() — without correlation, your test silently fails to represent real user behaviour
• Think time and pacing: simulating realistic user cadence with sleep() or JMeter's Constant Throughput Timer — why omitting think time creates an artificial thundering-herd scenario that overstates load and invalidates results

// PRACTISE

• Write a JMeter test plan against reqres.in or httpbin.org: thread group of 50 users, 60-second ramp-up, 3-minute hold, HTTP Sampler with a Response Assertion on status code and response body — run it and screenshot the Aggregate Report
• Write the same scenario in k6: 50 VUs, stages array for ramp-up/hold/ramp-down, thresholds set to fail if p95 > 2 s or error rate > 1%, and a check on status code for every request
• Add parameterisation to both scripts: load test usernames and email addresses from a CSV file so no two virtual users send identical request bodies — verify the CSV is consumed correctly in the Aggregate Report

// STUDY

• Workload modelling: identifying the user journeys to simulate, their relative transaction mix (e.g. 60% browse / 30% search / 10% checkout), and how to convert real traffic data or business estimates into a k6 or JMeter scenario
• Bottleneck identification: CPU and memory saturation, database connection pool exhaustion, GC pause spikes, external dependency latency — the signal each leaves in the results (throughput plateau, error spike, p99 spike while p50 stays stable)
• Reading results: Grafana + InfluxDB real-time dashboards, JMeter Aggregate Report columns (average, median, p90, p95, p99, error%), and k6 end-of-run summary — how to correlate a throughput plateau with an error spike
• Findings report structure: observed metric vs NFR threshold, likely root cause, how you would confirm the root cause, and remediation options — written for both an engineering audience and a product manager

// PRACTISE

• Run a stress test that intentionally exceeds the target system's capacity: ramp VUs beyond the point where p95 exceeds 2 s or errors appear — capture the breakdown point (VU count, throughput, error rate, p99) in your Aggregate Report or k6 summary
• From the raw results, write a structured 1-page findings report: what degraded, at what user count, what the likely bottleneck is, and what further investigation you would request from the engineering team
• Given this fabricated results table: at 200 VUs p50 = 180 ms / p99 = 420 ms / error = 0.0%; at 400 VUs p50 = 210 ms / p99 = 4,200 ms / error = 2.3%; at 500 VUs p50 = 230 ms / p99 = 12,000 ms / error = 8.7% — write a diagnosis paragraph identifying what the numbers indicate and the first 3 things you would check

// STUDY

• Performance bank: test type selection reasoning, NFR definition and validation, percentile metrics, JMeter Listeners interpretation, k6 thresholds and checks syntax, and bottleneck diagnosis patterns
• CI/CD bank: integrating k6 or JMeter into a GitHub Actions pipeline, threshold-gated build failures, publishing HTML results as artifacts — increasingly common in senior performance interviews
• Behavioural bank: critical bottleneck found two days before release, a stakeholder dismissing p99 data as 'edge cases', a test environment too small to simulate production traffic — practise structured STAR answers
• Revisit any tool syntax (JMeter JSON Path Extractor, k6 stages, thresholds format) that felt shaky or caused errors during Days 4–7

// PRACTISE

• Answer 10 questions aloud from the performance testing and CI/CD question banks — time yourself at 90 seconds per answer and flag every question where you gave a definition rather than a concrete example
• Identify your 5 weakest answers and write a worked example for each, referencing the scripts and findings report you produced during the plan
• Run a 30-minute timed mock: given an NFR brief, design a load test on paper — scenario, ramp shape, duration, parameterisation strategy, and pass/fail threshold definitions — then present it aloud in 5 minutes as you would to a senior engineer