test-strategy
Acerca de
Esta habilidad ayuda a los ingenieros de QA a crear planes de prueba defendibles, reemplazando porcentajes de cobertura sin sentido con estrategias metódicas como proporciones de pirámide de pruebas y puntuación de mutación. Genera un documento TEST-STRATEGY-{slug}.md para funcionalidades medianas/grandes, que luego es validado por una puerta de control de QA. Úsala al planificar pruebas para cambios significativos, asegurando que tu cobertura refleje realmente un enfoque de pruebas bien meditado.
Instalación rápida
Claude Code
Recomendadonpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/test-strategyCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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.skipforever. - Root-cause before re-enabling (shared state, timing, real network, ordering).
- This is the same discipline the eval runner needs (see the eval
flakyflag intests/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".
Repositorio GitHub
Frequently asked questions
What is the test-strategy skill?
test-strategy is a Claude Skill by avelikiy. Skills package instructions and resources that Claude loads on demand, so Claude can perform test-strategy-related tasks without extra prompting.
How do I install test-strategy?
Use the install commands on this page: add test-strategy to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does test-strategy belong to?
test-strategy is in the Testing category, tagged testing and design.
Is test-strategy free to use?
Yes. test-strategy is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
Esta Skill de Claude ejecuta el benchmark lm-evaluation-harness para evaluar modelos de lenguaje en más de 60 tareas académicas estandarizadas como MMLU y GSM8K. Está diseñada para que los desarrolladores comparen la calidad de los modelos, realicen seguimiento del progreso del entrenamiento o reporten resultados académicos. La herramienta admite varios backends, incluidos modelos de HuggingFace y vLLM.
Esta habilidad proporciona conocimiento integral para implementar Cron Triggers de Cloudflare y programar Workers mediante expresiones cron. Cubre la configuración de tareas periódicas, trabajos de mantenimiento y flujos de trabajo automatizados, manejando problemas comunes como expresiones cron inválidas y inconvenientes de zonas horarias. Los desarrolladores pueden utilizarla para configurar manejadores programados, probar activadores cron e integrar con Workflows y Green Compute.
Esta habilidad de Claude proporciona un kit de herramientas basado en Playwright para probar aplicaciones web locales mediante scripts de Python. Permite verificación de frontend, depuración de interfaz de usuario, captura de pantallas y visualización de registros, mientras gestiona los ciclos de vida del servidor. Úsela para tareas de automatización de navegadores, pero ejecute los scripts directamente en lugar de leer su código fuente para evitar contaminación del contexto.
Esta habilidad ayuda a los desarrolladores a completar el trabajo terminado verificando que las pruebas pasen y luego presentando opciones estructuradas de integración. Guía el flujo de trabajo para fusionar, crear PRs o limpiar ramas después de que se completa la implementación. Úsala cuando tu código esté listo y probado para finalizar sistemáticamente el proceso de desarrollo.
