WJTTC Championship Tester

"We break things so others never have to know they were broken."

Apply F1-inspired standards to software testing. When brakes must work flawlessly at race pace, so must the code in production. This skill executes test plans and files reports — it is the driver, not the engineer. To plan and generate the suite, use wjttc-builder.

When to use this skill

• Running an existing or just-written test plan and reporting outcomes
• Reproducing and root-causing a reported bug
• Edge-case / error-handling / regression validation
• Auditing whether the suite's CI signal can still be trusted
• Producing a WJTTC report with a tier verdict

The WJTTC five tiers

Triage every test by blast radius. The first three set severity; Tyre and Pit cover durability and the release gate.

Test Brake first. If the brakes don't work, nothing else matters.

Step 0 — Signal Integrity pre-audit (run BEFORE adding/running anything new)

Red CI is a contract: it must always mean "stop, look, fix." A suite with high coverage but flaky reds is less trustworthy than a smaller suite with zero false alarms — because the team has stopped reading the reds. Fix the signal before you add more tests.

Method — classify the last 30 days of CI failures:

Signal Integrity Score: SI = Real bugs / (Real bugs + Flakes + Infra) × 100

Eliminate on sight: hard absolute-time perf asserts on shared runners (expect(t).toBeLessThan(30)) → move to a non-gating workflow; network calls in the main suite → mock at the boundary; concurrency tests without explicit ordering; secret-dependent steps that hard-fail when missing → grey-skip.

The inverse rule: green CI that passes while something is broken is equally a violation. If a real bug shipped despite green, write the regression test BEFORE the fix lands.

The conversation is the real gate. CI is supporting infrastructure for the human + AI audit; flaky CI wastes the audit's bandwidth. Signal Integrity keeps CI worthy of the conversation.

Execution loop

1. Scope — what should it do? happy path, edges, failure modes, perf targets, tier of each.
2. Audit signal (Step 0) before trusting or extending the suite.
3. Run each test: set up, prepare data, execute, observe actual vs expected, record pass/fail/blocked, capture evidence on failure.
4. Reproduce every failure deterministically; root-cause it; note the fix.
5. Tier coverage check — confirm every test is tiered:

   faf wjttc --path tests          # audit tier coverage (vendor-neutral)
   faf wjttc --strict --json       # CI gate: non-zero if any test is untiered
   

6. Report — file the WJTTC report (below), then surface the tier verdict.

WJTTC report format

Save reports to ./wjttc-reports/ in the project under test (or a path the user specifies). Never write to an absolute/personal path. Name files YYYY-MM-DD-{project}-{feature}-tests.yaml.

---
# WJTTC Test Report
project: "project-name"

…