qa-load-testing
Load and performance testing: 12 skills (db-slow-query-detector, flame-graph-analyzer, gatling-load-testing, jmeter-load-testing, jvm-gc-tuning, k6-load-testing, latency-percentile-analyzer, lighthouse-budget-author, lighthouse-perf, load-testing-getting-started, locust-load-testing, perf-budget-gate) and 3 agents (load-test-tool-selector, perf-incident-responder, perf-regression-bisector).
Install this plugin
/plugin install qa-load-testing@testland-qaPart of role bundles: qa-role-sdet, qa-role-performance
qa-load-testing
Load and performance testing: k6, JMeter, Gatling, Locust runners; Lighthouse CI for Web Vitals; perf budget gate; flame-graph analyzer; DB slow-query detector; perf regression bisector.
Components
| Type | Name | Description |
|---|---|---|
| Skill | k6-load-testing | Author k6 JavaScript load tests with stages + thresholds; CI gate via k6 run exit code. |
| Skill | jmeter-load-testing | Run .jmx test plans via jmeter -n -t CLI; HTML dashboard via -e -o; JTL parsing for CI gates. |
| Skill | gatling-load-testing | Author Gatling Simulation classes (Java/Kotlin/Scala/JS); injectOpen vs injectClosed; setUp().assertions() as the CI gate. |
| Skill | locust-load-testing | Author Python locustfile.py with HttpUser + @task; run headless with --users / --spawn-rate; CSV / HTML reports for CI gates. |
| Skill | lighthouse-perf | Lighthouse CI for Web Vitals (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1) at 75th percentile; per-PR assertions + reports. |
| Skill | perf-budget-gate | Aggregate k6 / JMeter / Gatling / Locust / Lighthouse verdicts into a unified go/no-go gate with delta vs baseline. |
| Skill | lighthouse-budget-author | Draft .lighthouserc.js per-route LCP/INP/CLS thresholds + budget.json resource-size caps at design time. |
| Skill | flame-graph-analyzer | Read py-spy / async-profiler / pprof / clinic.js folded stacks; classify CPU-bound / GC / lock-contention; propose remediation. |
| Skill | db-slow-query-detector | Read EXPLAIN ANALYZE; identify dominant cost (seq-scan / sort spill / nested loop); propose specific index or rewrite. |
| Agent | perf-regression-bisector | git bisect run against a per-commit perf measurement (k6 / Lighthouse); hand off culprit to flame-graph or db-slow-query analysis. |
| Agent | load-test-tool-selector | Reads project stack + load-testing goal (RPS profile, soak duration, browser-side metrics, CI gating) and recommends one tool from k6 / JMeter / Gatling / Locust / Lighthouse. Refuses when goal lacks a concrete load profile. Sibling of qa-mutation-testing/mutation-tool-selector. |
| Agent | perf-incident-responder | On-call perf-incident orchestrator: confirm with k6, flame-graph the hot path, check slow queries, localize the cause. |
| Skill | latency-percentile-analyzer | Interpret latency distributions beyond p95/p99: tail ratio, bimodal detection, coordinated omission. |
| Skill | jvm-gc-tuning | Diagnose JVM GC under load: GC logs, collector selection, the GC-pause to latency-tail link. |
| Skill | load-testing-getting-started | Junior on-ramp: load-testing metrics, which tool to pick, and a first k6 run + threshold. |
Install
/plugin marketplace add testland/qa
/plugin install qa-load-testing@testland-qaSkills
db-slow-query-detector
Reads `EXPLAIN` / `EXPLAIN ANALYZE` output from PostgreSQL, MySQL, or SQLite - identifies the dominant cost (sequential scan, nested loop, sort spill, missing index, type-cast preventing index use), proposes the specific index or query rewrite to fix it, and emits the candidate `CREATE INDEX` statement. Use when load testing or production telemetry shows the database as the bottleneck and the team needs targeted query-level remediation.
flame-graph-analyzer
Reads CPU flame-graph output from py-spy (Python), async-profiler (JVM), Go pprof, or Node.js perf_hooks / clinic.js - identifies the hot path (top sample-time stack frames), classifies the bottleneck (CPU-bound vs lock contention vs allocator pressure), and proposes the next investigation step. Use when a perf regression has been bisected to a commit but the hot path inside that commit is unclear.
gatling-load-testing
Authors Gatling simulations in Java / Kotlin / Scala (or JS / TS) using the Simulation class plus http() / scenario() / exec() DSL builders, ramps virtual users via injectOpen (arrival rate) or injectClosed (concurrent count), runs via Maven / Gradle / sbt with the Gatling plugin, and gates CI on assertions defined in setUp(). Use when the project is on the JVM and the team prefers code-first load tests over JMeter's XML or k6's JavaScript-only authoring.
jmeter-load-testing
Authors Apache JMeter `.jmx` test plans (Thread Groups + HTTP samplers + assertions + listeners) in the JMeter GUI, runs them headlessly via `jmeter -n -t plan.jmx -l results.jtl`, generates an HTML dashboard with `-e -o`, and gates CI on JTL parsing. Use when the project has an existing JMeter investment, needs JVM-native load tooling, or works in domains with strong JMeter community support (banking, telecom, enterprise).
jvm-gc-tuning
Diagnoses JVM garbage-collection behaviour under load: reads and interprets unified GC logs (-Xlog:gc*), selects the right collector (G1 vs ZGC vs Parallel vs Serial), tunes heap sizing and pause-time targets, quantifies allocation rate, and traces the GC-pause-to-latency-tail link using GCViewer and Java Flight Recorder (JFR). Use when a load test reveals p99/p999 latency spikes that correlate with GC activity, or when heap sizing and collector selection need justification before a performance baseline is locked.
k6-load-testing
Authors k6 JavaScript load-test scripts (VU loops + checks + sleeps), configures the `options` block with `stages` (ramp-up patterns) and `thresholds` (p(95) latency, error rate), runs via `k6 run script.js` or `--vus / --duration` ad-hoc flags, and uses thresholds as the CI pass/fail signal. Use when the project ships HTTP / WebSocket / gRPC load tests and the team wants developer-friendly JavaScript authoring.
latency-percentile-analyzer
Interprets latency distributions from k6 load tests beyond the p95/p99 gate: reads percentile summaries and JSON exports to identify tail shape, computes the tail ratio (p99/p50) as a distribution-spread signal, detects bimodal distributions, explains coordinated omission and why naive p99 values are optimistic under sustained load, and distinguishes request-rate from concurrency models. Use when a k6 threshold passes but the system still feels slow, when p99 is suspiciously low during ramp-up, or when the team needs to explain why tail latency is high rather than just observing that it is.
lighthouse-budget-author
Drafts a `lighthouserc.js` (or `budget.json`) at design time - picks Web Vitals thresholds (LCP / INP / CLS) per route based on traffic class (cached / dynamic / API-heavy / form-heavy) and the team's NFRs, plus resource-size budgets (JS / CSS / images / total bytes). Emits the config file ready for the lighthouse-perf runner. Use when starting Lighthouse coverage on a project that has no budgets yet, or when the existing budgets need a redesign.
lighthouse-perf
Configures Lighthouse CI (`@lhci/cli`) to audit Web Vitals (LCP, INP, CLS) on every PR, asserts against canonical thresholds (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 at the 75th percentile), uploads Lighthouse reports as build artifacts, and posts deltas as PR comments. Use when the project ships a web frontend and the team needs continuous Web Vitals monitoring tied to PR gating.
load-testing-getting-started
Orients an engineer who is new to performance and load testing through the qa-load-testing plugin: explains the core metrics (throughput, latency percentiles, error rate), selects the right tool via the load-test-tool-selector agent, walks the first k6 script through to a passing threshold, adds a perf-budget-gate CI step, and routes failing results to latency-percentile-analyzer or perf-incident-responder. Use when an engineer new to performance or load testing does not know where to start in this plugin.
locust-load-testing
Authors Locust load tests as Python classes - HttpUser with @task-decorated methods plus on_start hooks and between() wait_time - runs via `locust -f locustfile.py` headless mode (or distributed via `--master` / `--worker`), and exports CSV / JUnit reports for CI gating. Use when the project's primary stack is Python and the team wants load tests in the same language as the application.
perf-budget-gate
Builds a unified release-readiness gate that aggregates verdicts from any combination of k6 / JMeter / Gatling / Locust load runners and Lighthouse CI Web Vitals, applies severity-aware pass/fail thresholds, and emits a single go / no-go decision with per-metric deltas vs the main-branch baseline. Posts the delta as a PR comment when the team has the integration set up. Use when authoring a CI step that gates a deployment on cross-runner perf compatibility.
Agents
load-test-tool-selector
Action-taking agent that reads a target project's stack + load-testing goal (RPS profile, soak duration, browser-side metrics, CI gating) and recommends ONE load testing tool - k6 (JS scripts), JMeter (GUI / XML scenarios), Gatling (Scala DSL), Locust (Python), or Lighthouse (browser-side perf budgets) - plus rationale and the preloaded SKILL.md to read next. Distinct from `qa-load-testing/perf-regression-bisector` (bisects regressions in EXISTING load-test data). Use when starting a new load testing effort and the team has not yet committed to a tool.
perf-incident-responder
Action-taking on-call orchestrator that confirms a live performance incident, reproduces it under k6 load, flame-graphs the hot path, detects slow queries, localizes the dominant cause, and emits a triage report with a recommended fix. Distinct from `perf-regression-bisector` (which bisects commits to find the introducing change) - this agent acts on an active incident where the symptom is confirmed but the cause is unknown. Use when an alert, APM spike, or customer report signals a performance incident and the on-call engineer needs to localize the cause under time pressure.
perf-regression-bisector
Action-taking agent that bisects a performance regression across commits - drives `git bisect run` with a per-commit perf measurement script (typically a k6 / Lighthouse run with a single budget assertion), identifies the introducing commit, and hands off the in-commit hot path to flame-graph-analyzer or db-slow-query-detector for application-level diagnosis. Use when load testing or Lighthouse CI shows a perf regression but the introducing commit is unclear.