From alfred-dev
Generates a structured testing plan prioritized by risk, covering unit, integration, e2e tests, edge cases, and negative scenarios. Analyzes impact, probability, and visibility to focus on critical areas.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devThis skill uses the workspace's default tool permissions.
Este skill produce un plan de testing estructurado y priorizado por riesgo. No se trata de probar todo con la misma intensidad, sino de concentrar el esfuerzo donde más impacto tiene: las áreas críticas del sistema que, si fallan, causan mayor daño al usuario o al negocio.
Create testing pyramid with unit/integration/E2E strategy. Define coverage targets and high-risk testing. Use when planning tests for features.
Produce a test strategy for a project or feature — risk map, test type decisions, coverage targets, CI config. Use when asked to "create test strategy", "what should we test", "testing plan", or "improve test coverage".
Designs test strategies and plans with testing pyramid. Covers APIs, frontend, data pipelines, infrastructure; outputs plans including coverage targets, examples, and gaps.
Share bugs, ideas, or general feedback.
Este skill produce un plan de testing estructurado y priorizado por riesgo. No se trata de probar todo con la misma intensidad, sino de concentrar el esfuerzo donde más impacto tiene: las áreas críticas del sistema que, si fallan, causan mayor daño al usuario o al negocio.
El plan cubre desde tests unitarios hasta tests end-to-end, pasando por integración, edge cases y escenarios negativos. El resultado es un documento accionable que guía el esfuerzo de testing.
Identificar el alcance. Definir qué se va a probar: una feature nueva, un módulo refactorizado, el sistema completo, o un área específica. El alcance determina la profundidad del plan.
Analizar el riesgo de cada área. Para cada componente o funcionalidad, evaluar:
Clasificar cada área como crítica, alta, media o baja prioridad de testing.
Definir las categorías de tests:
Asignar prioridad a cada test:
| Prioridad | Criterio | Ejemplo |
|---|---|---|
| Crítica | Fallo = pérdida de datos o dinero | Test de transacciones, test de backup |
| Alta | Fallo = servicio no disponible | Test de autenticación, test de endpoints principales |
| Media | Fallo = mala experiencia de usuario | Test de validación de formularios, test de paginación |
| Baja | Fallo = molestia menor | Test de formato de fecha, test de ordenación |
Estimar el esfuerzo. Para cada grupo de tests, estimar el tiempo necesario para escribirlos. Esto ayuda a planificar sprints y a negociar alcance si hay restricciones de tiempo.
Documentar el plan. Utilizar templates/test-plan.md si existe. El documento debe ser una referencia viva que se actualiza conforme el proyecto evoluciona.
Registrar las decisiones de estrategia de testing en la memoria del proyecto con memory_log_decision. Esto incluye qué áreas se han priorizado, qué se ha descartado y por qué, para que el plan se mantenga coherente entre sesiones.
Consultar el stack detectado en la configuración de Alfred para seleccionar automáticamente el framework de testing adecuado (Jest, Vitest, pytest, etc.) y adaptar las recomendaciones al ecosistema del proyecto.