test-strategy · avelikiy — скилл для Claude Code: план тестов
Скилл для QA-инженера: превращает «покрытие 90%» в обоснованный план — что тестировать, почему именно это и как понять, что тесты действительно ловят баги.
npx skills add avelikiy/great_cto --skill test-strategy -a claude-codeЧто делает test-strategy
Скилл test-strategy задаёт метод проектирования покрытия для средних и крупных фич. Вместо рефлекторного «напишем побольше тестов» он заставляет ответить на четыре вопроса: какое соотношение unit/integration/e2e подходит под архетип проекта, какие классы эквивалентности и границы проверить, какой mutation score подтверждает, что тесты кусаются, и что делать с флаки-тестами.
Пирамида выбирается по архетипу, а не по привычке. Для библиотеки это 80% unit / 15% integration / 5% e2e, для коммерса с денежными путями — 50% / 35% / 15%. AI-система получает отдельный столбец: 50% unit, 20% integration, 10% e2e и 20% evals. Любое отклонение от таблицы нужно обосновать прямо в плане.
Главный сигнал — mutation score, а не покрытие строк. Модуль с 90% line coverage и 30% mutation score содержит тесты без ассертов: они просто гоняют код. Поэтому цель — mutation score ≥ 60% на изменённых логически плотных файлах, результат попадает в отчёт.
Флаки-тесты скилл предлагает не терпеть, а карантинить: пропустить, завести баг с владельцем и сроком, найти причину до повторного включения. Тест, который падает случайно, портит сигнал всей пачке — хуже, чем отсутствие теста.
Результат — файл docs/qa-reports/TEST-STRATEGY-{slug}.md. QA-гейт проверяет, что он существует для средних и крупных фич. Для типографики и переименований скилл не нужен: оверхед превышает пользу.
Какие задачи решает
- выбрать соотношение unit/integration/e2e под архетип проекта, а не наугад
- разбить входные данные на классы эквивалентности и границы вместо перебора значений
- проверить, что тесты падают при поломке кода, через mutation score
- изолировать флаки-тесты и довести их до причины
- получить план, который объясняет выбор набора тестов, а не только процент покрытия
Примеры запросов агенту
- Составь тестовую стратегию для фичи расчёта скидок в корзине
- Проверь, оправдан ли текущий процент покрытия в модуле оплаты, и выдай план по mutation score
- Какие граничные случаи и классы эквивалентности учесть для парсера CSV?
Как установить test-strategy
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a claude-code2Вручную: положить файлы
~/.claude/skills/test-strategy/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/test-strategy/
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a codex2Вручную: положить файлы
.agents/skills/test-strategy/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a cursor2Вручную: положить файлы
.cursor/skills/test-strategy/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install avelikiy/great_cto test-strategy2Вручную: положить файлы
.github/skills/test-strategy/SKILL.md1Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a gemini-cli2Командой платформы
gemini skills install https://github.com/avelikiy/great_cto --path skills/test-strategyВручную: положить файлы
.devin/skills/test-strategy/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о test-strategy
Как установить test-strategy в Claude Code?
Выполни npx skills add avelikiy/great_cto --skill test-strategy -a claude-code, скилл окажется в ~/.claude/skills/test-strategy/SKILL.md.
Что делает test-strategy?
Даёт метод планирования тестов: пирамиду по архетипу, выбор случаев через классы эквивалентности и границы, mutation score как сигнал качества и политику карантина флаки-тестов. Результат — файл TEST-STRATEGY-{slug}.md.
Чем mutation score лучше обычного покрытия?
Покрытие строк показывает, что код выполнялся. Mutation score проверяет, что тест упадёт при поломке логики: мутатор переворачивает операторы и условия, а тесты должны это поймать. Модуль с высоким покрытием и низким mutation score содержит тесты без ассертов.
Исходный текст
SKILL.md · MIT
---
name: test-strategy
description: Coverage-design method for qa-engineer — pyramid ratios per archetype, equivalence/boundary/property case selection, mutation score as the real coverage signal, and a flake-quarantine policy. Turns "coverage is 90%" (a number with no method) into a defensible test plan. Emits TEST-STRATEGY-{slug}.md, which the QA gate checks exists.
when_to_use: |
Apply when:
- qa-engineer is planning tests for a medium/large feature (>1 file, real behaviour risk)
- a coverage % is being reported and you need to know whether it MEANS anything
- deciding what to test (not just measuring what's covered)
Do NOT apply to:
- nano / tiny changes (typo, rename) — overhead exceeds value
- pure docs changes
effort: medium
allowed-tools: Read, Write, Grep, Glob, Bash
paths:
- "tests/**"
- "docs/qa-reports/**"
---
# test-strategy
Coverage % is a number with no method. This skill makes the QA plan defensible:
**what** to test, **why** that set, and a **real** signal that the tests bite.
qa-engineer emits `docs/qa-reports/TEST-STRATEGY-{slug}.md` capturing the four
decisions below; the QA gate checks the file exists for medium/large features.
## 1. Pyramid ratio — pick by archetype (not by reflex)
The right unit:integration:e2e mix depends on where the risk lives.
| Archetype | unit | integration | e2e | why |
|-----------|------|-------------|-----|-----|
| library / devtools / cli | 80% | 15% | 5% | logic-dense, few I/O seams |
| web-app / saas | 60% | 30% | 10% | request→db→render seams dominate |
| commerce / fintech / marketplace | 50% | 35% | 15% | money paths need cross-component proof |
| data-platform / streaming | 45% | 45% | 10% | correctness lives in pipelines, not units |
| ai-system / agent-product | 50% | 20% | 10% + **evals 20%** | behaviour is the contract → eval set (see [[decision-eval]]) |
State the chosen ratio in TEST-STRATEGY and justify any deviation.
## 2. Case selection — equivalence / boundary / property
Don't enumerate inputs; **partition** them.
- **Equivalence classes** — one representative per class of behaviour (valid, invalid, empty, max). Testing 5 valid ids ≠ testing 5 classes.
- **Boundaries** — the bug lives at the edge: 0, 1, n-1, n, n+1, off-by-one, empty, overflow, the threshold itself.
- **Property-based** — for pure/transform logic, assert invariants over generated input (round-trip `decode(encode(x))===x`, idempotency, ordering) instead of hand-picked cases. Use fast-check / Hypothesis where the logic warrants it.
## 3. Mutation score — the only coverage that proves the tests bite
Line/branch coverage proves code *ran*, not that a test would *fail* if it broke.
**Mutation testing** (Stryker / mutmut / cargo-mutants) flips operators/conditions
and checks a test catches it. A "90% covered" module with 30% mutation score has
assertion-free tests. Target: mutation score ≥ 60% on changed logic-dense files;
report it in TEST-STRATEGY when the change is logic-heavy. Coverage % is the cheap
proxy; mutation score is the truth.
## 4. Flake quarantine — a flaky test is worse than no test
A test that fails ~randomly trains the team to ignore red. Policy:
- A test that fails non-deterministically is **quarantined** (skipped + tracked in a Beads bug), not left to rot the signal.
- Quarantine is time-boxed: a bug with an owner and a deadline, not `it.skip` forever.
- Root-cause before re-enabling (shared state, timing, real network, ordering).
- This is the same discipline the eval runner needs (see the eval `flaky` flag in
`tests/eval/runner.mjs` — stddev > 0.1 is a flake signal).
## Output: TEST-STRATEGY-{slug}.md
```
# TEST-STRATEGY-{slug}
- Archetype + chosen pyramid ratio (+ justification for any deviation)
- Equivalence classes & boundaries enumerated per changed unit
- Property-based candidates (which logic, which invariants)
- Mutation-score target + result (for logic-dense changes)
- Quarantine list (flaky tests + their tracking bug)
```
Done = the plan answers "why THIS set of tests", not just "how much is covered".
© avelikiy · MIT · avelikiy/great_cto
Похожие скиллы
Все скиллы по теме «Тесты и QA» →Сначала — test-strategy от других авторов.