What it does
Treats the automation codebase as the test object: maps it to the gTAA, evaluates SOLID/clean-code, test-case/design quality (ISTQB + FIRST), anti-patterns/flakiness, pyramid distribution and CI health, then writes a scored health report with a prioritized remediation roadmap routed to the commands that do the work. Modifies nothing in the audited suite.
When to use it
Onboarding or inheriting a suite, or a periodic (quarterly) health check.
Prerequisites
qa.config.yml (paths.* for report location, tooling.*, gates, risk_areas) — stack/risk inferred from the repo if absent; a path/module to focus on, or the whole project.
Output
Automation Project Assessment Report (static-testing review of testware; scores ISO/IEC 25010 maintainability) -> docs/AUTOMATION-AUDIT.md.
Mechanics
How it works
- Scope from $ARGUMENTS; read representative files across each layer (not grep counts alone)
- Architecture & gTAA layering: separation of concerns, structure, config, data, reporting
- SOLID & design principles applied to test code, with file:line evidence
- Test-case & design quality (ISTQB techniques + FIRST), assertion quality, traceability
- Anti-patterns & flakiness (hard waits, fragile selectors, hardcoded secrets, skips)
- Pyramid/level distribution and CI/CD health; write a maturity scorecard + routed roadmap
Why it works
The theory behind it
Static testing of testware + CT-TAE architecture assessment, scored against ISO/IEC 25010 maintainability (modularity, reusability, analysability, modifiability, testability). The audit is sampled, not exhaustive (Principle 2); it reports residual risk, never 'the suite is defect-free' (Principle 1); analysis must never mutate the thing it judges.
CTFL v4.0 §3.1 · CT-TAE · ISO/IEC 25010 (maintainability)
Example
See it in use
> /qa:automation-audit tests✓ Correct when It scores Architecture/SOLID/Design-quality/Anti-patterns/Pyramid/CI (1–5), cites file:line evidence, and changes no code.
Used by