Performance Testing

In brief: TestChimp performance testing is k6 in your repo—journeys and composites authored by agentic workflows, linked to scenarios, run after PRs and releases, and compared against prior runs so you catch design choices that break under concurrency and data volume.

Functional tests (SmartTests) prove the product works. Performance tests prove it still works when many users arrive at once or when a tenant already has a lot of data. Those are different questions. Agent-authored code often passes the first and fails the second.

This section is the authoritative product documentation for TestChimp performance testing: why it exists, how k6/ is organized, the dedicated workflows, and how to read results.

What TestChimp performance testing is

TestChimp performance tests are Grafana k6 scripts that live under your mapped tests folder in a reserved k6/ tree. They are not Playwright SmartTests. Playwright config ignores **/k6/**. Perf does not run inside /testchimp test.

Each file is one k6 run:

Kind	What it answers	When you typically run it
Journey	Does this user path degrade in isolation? One journey may cover several #TS-… scenarios.	After a PR; local debug; release-related paths
Composite	Can the system handle a realistic mix of journeys (weighted)?	Release / nightly; after adding a journey (membership is explicit)

Two independent test types sit on those files:

• Load testing — many concurrent users (virtual users / arrival rate).
• Volume testing — one user or tenant with a large dataset (cardinality, records, bytes). Making a test “heavier” by raising both at once hides which axis broke.

Agents author journeys from real scenarios, redacted API interaction shapes, and relative demand from TrueCoverage. They never turn those observations into absolute VUs, RPS, duration, or dataset size. Capacity numbers come from you (or run-perf-tests.policy.md).

Capability: org capability PERFORMANCE_TESTING (Growth plan and free trial). Without it, perf workflows are N/A—they do not scaffold a suite you cannot run.

Questions performance testing helps answer

These are the questions teams actually need before they ship—not “did p95 look pretty on a one-off dashboard.”

Business question	What a TestChimp perf run is for
Will checkout still complete if Black Friday traffic hits this endpoint mix?	Load journeys + a release composite against an approved isolated environment
Does the reports page still render when this tenant already has 100k invoices?	Volume journeys with a versioned dataset manifest—not a bigger VU count
Did this PR make the hot path slower than last week’s baseline?	Related journeys after the PR, then compare to a prior run on matching environment / profile / dataset
If we include this new journey in the evening mix, does the system still hold?	Composite membership with an explicit weight—absolute load stays a separate decision
Are we testing the real query path, or a stub that returns in 0 ms?	External dependencies mocked with realistic latency so queues and pools actually fill

Thresholds tell you pass/fail against the policy you approved. Comparisons tell you whether this cut is worse than a comparable prior run. Both matter. Green against a weak threshold can still be a regression versus last Tuesday.

Why this matters for agent and vibe-coded teams

Coding agents are unusually good at core functionality. Given a story, they often produce a UI that works, an API that returns 200, and a SmartTest that is green for a single user on a nearly empty database.

They are much less reliable at design under scale:

• An N+1 query hidden behind a list that “looks fine” with three rows
• A missing index that never shows up until the table has real history
• Chatty client-to-API round trips that work at 1 VU and queue at 50
• Unbounded SELECT * / in-memory maps that explode with tenant volume
• Live calls to payments, email, or LLMs in the test path (flaky, expensive) or stubs that return in 0 ms (false confidence)

Those are not “the test was flaky.” They are product failures that only appear under concurrency or data volume—exactly the conditions users create and agents rarely exercise while coding.

If your team ships from agent PRs every day, functional coverage can grow faster than anyone’s instinct for “will this hold?” Performance testing is how you put that instinct on a leash: scenario-linked journeys in Git, run on the impacted surface after a PR or a release, with results you can compare instead of eyeballing a one-off k6 chart.

How it fits the TestChimp stack

1. Plans — markdown scenarios remain the requirement source. Perf journeys link the same #TS-… ordinals as SmartTests.
2. /testchimp init-perf — scaffolds portable k6/ assets and perf policies (once per repo).
3. /testchimp create-perf-tests — authors journeys (and composites only with membership approval).
4. /testchimp run-perf-tests — script-first execution of related journeys for a PR, or a release git range, with optional nested authoring when coverage is insufficient.
5. /testchimp upkeep-perf — keeps composites, scenario links, and thresholds honest as the product moves.
6. Executions — ingest + timeseries land on Executions → Performance Tests so you can view a run and overlay a prior one.

TrueCoverage, API interaction evidence, and related-selection tell agents which paths deserve a journey. They never silently raise VUs. Load/volume profiles stay smoke until you approve real capacity numbers.

What you should not expect

• Perf is not a substitute for SmartTests. A green load run does not prove the UI assertion still holds.
• Perf is not inside Run QA. Keep functional smoke fast; run related k6 on a dedicated job or agent invoke.
• Perf is not “copy production RPS into k6.” Relative demand ranks journeys; you set the absolute profile.
• Zero-latency mocks are not a valid default for load or volume. They hide the failure modes you are trying to find.

Concept guides (load, volume, k6, regressions)

These Testing Guides pages explain the discipline; this section is how TestChimp runs it:

• What is load testing?
• What is volume testing?
• Load testing patterns — ramp, spike, soak, stress, arrival rate
• Metrics: p95, 4xx, 5xx, fail rate
• k6 vs JMeter vs Locust
• Performance regression testing — compare cuts; git SHA → release

Hub: Performance testing guides.

Next steps

• How performance tests are organized — k6/ layout and what a run captures
• Authoring workflows — init, create, run (PR and release), upkeep, import
• Viewing results and comparing runs — Executions UI, thresholds, overlays
• SmartTests (functional testing) — Playwright / Mobilewright for correctness