Plantilla de Estrategia de Pruebas

Overview

Un documento de estrategia de pruebas define cómo un equipo aborda el aseguramiento de la calidad en un proyecto o producto. Alinea a los interesados sobre qué se prueba, en qué nivel, con qué herramientas y qué gates deben superarse antes del despliegue. Sin uno, los equipos caen en pruebas ad-hoc: algunas áreas se prueban de más, las rutas críticas quedan sin cubrir y nadie puede decirte cómo está la cobertura del proyecto.

When to Use

• Al empezar un proyecto nuevo o una área de funcionalidad importante
• Al incorporar un miembro nuevo al equipo y sus prácticas de pruebas
• Al auditar por qué los bugs siguen llegando a producción a pesar de tener una suite decente
• Al alinear a varios equipos en estándares de calidad compartidos
• Al preparar auditorías de cumplimiento (SOC 2, ISO 27001, FDA)

Para la parte de toma de decisiones — en qué tipos de prueba invertir y cómo secuenciarlas — consulta la Guía de Estrategia de Testing. Esta plantilla asume que ya tomaste esas decisiones y necesitas dejarlas por escrito.

Solution

# Estrategia de Pruebas: `<Nombre del Proyecto>`

## 1. Objetivos

- Verificar que el producto cumple los requisitos funcionales
- Prevenir regresiones en los recorridos críticos del usuario
- Validar el rendimiento bajo carga esperada y de pico
- Garantizar la seguridad y la integridad de los datos
- Dar feedback rápido a los desarrolladores (menos de 10 minutos en el pipeline de PR)

## 2. Pirámide de Pruebas

| Capa | Proporción | Alcance | Velocidad | Responsable |
|------|-----------|---------|-----------|-------------|
| Unit | 70% | Funciones, clases, módulos | < 30s | Developer |
| Integration | 20% | API + base de datos + servicios externos | < 5min | Developer |
| E2E | 7% | Recorridos completos del usuario | < 15min | QA |
| Manual/Exploratoria | 3% | Casos borde, usabilidad, seguridad | Según necesidad | QA |

### Justificación

Las pruebas unitarias son rápidas y aíslan los fallos. Las de integración verifican los contratos entre componentes. Las E2E validan flujos reales de usuario, pero son lentas y flaky. Las pruebas manuales cubren lo que la automatización no puede: bugs visuales, usabilidad y casos borde nuevos.

## 3. Alcance de las Pruebas

### Dentro del alcance

| Área | Objetivo de cobertura | Prioridad |
|------|----------------------|-----------|
| Autenticación y autorización | 95% | Crítica |
| Procesamiento de pagos | 95% | Crítica |
| Gestión de pedidos | 90% | Alta |
| Perfil de usuario | 80% | Media |
| Panel de administración | 70% | Baja |
| Páginas de marketing | 50% | Baja |

### Fuera del alcance

- Servicios de terceros (los prueban sus proveedores)
- Aprovisionamiento de infraestructura (lo validan las pruebas de Terraform)
- Regresión visual (la gestiona la revisión de diseño)

## 4. Entornos de Prueba

| Entorno | Propósito | Datos | Ciclo de actualización |
|---------|-----------|-------|------------------------|
| Local | Pruebas del desarrollador | Datos seed sintéticos | Bajo demanda |
| CI | Pipelines automatizados | Frescos en cada ejecución | Por build |
| Staging | Validación pre-producción | Snapshot anonimizado de prod | Semanal |
| Producción | Smoke tests, monitorización sintética | Reales | N/A |

### Requisitos de paridad entre entornos

- Misma versión y configuración de base de datos
- Mismo SO y versiones de runtime
- Mismas variables de entorno (excepto secretos)
- Mismas versiones de API de terceros (o mocks con comportamiento equivalente)

## 5. Herramientas y Frameworks

| Capa | Herramienta | Versión | Notas |
|------|-------------|---------|-------|
| Unit | Vitest / Jest | Latest | Cobertura vía v8 |
| Integration | Testcontainers + supertest | Latest | BD real en Docker |
| E2E | Playwright | Latest | Multi-navegador |
| Load | k6 | Latest | Basado en escenarios |
| Contract | Pact | Latest | Consumer-driven |
| Security | OWASP ZAP | Latest | DAST en CI |
| Coverage | c8 / istanbul | Latest | Instrumentación v8 |

## 6. Gates del Pipeline CI/CD

| Etapa | Pruebas | Condición del gate | Timeout |
|-------|---------|--------------------|----------|
| Pre-commit | Lint, type check | 0 errores | 30s |
| Build de PR | Unit + integration | 100% pass, cobertura >= 80% | 10min |
| Merge a main | Suite completa + contract | 100% pass, sin tests flaky nuevos | 20min |
| Nightly | E2E + baseline de carga | 95% pass, latencia dentro del 10% | 60min |
| Pre-release | Carga completa + soak + security | 100% pass, SLOs cumplidos | 120min |
| Post-release | Smoke tests + sintéticos | 100% pass durante 30min | 5min |

### Gates de cobertura

| Métrica | Umbral | Quién lo aplica |
|---------|--------|-----------------|
| Cobertura de líneas | >= 80% | Check de CI |
| Cobertura de ramas | >= 70% | Check de CI |
| Cobertura de rutas críticas | >= 95% | Revisión manual |
| Cobertura de código nuevo | >= 90% | Check de CI (por diff) |

## 7. Gestión de Datos de Prueba

| Estrategia | Caso de uso | Implementación |
|------------|-------------|----------------|
| Factory functions | La mayoría de los tests | Helpers `createUser()`, `createOrder()` |
| Datos seed | Tests de integración | Scripts SQL antes de la suite |
| Fixtures | Datos de referencia estables | Archivos JSON en control de versiones |
| Datos de prod anonimizados | Solo staging | Pipeline ETL que elimina datos personales |
| Datos sintéticos | Tests de carga | Generados a escala, sin datos personales |

### Limpieza de datos

- Cada test crea sus propios datos y los limpia (teardown)
- Los tests de integración usan transacciones que se revierten tras cada test
- Los datos de staging se refrescan semanalmente desde un snapshot anonimizado de producción
- Nada de datos de prueba en producción — forzado por aislamiento de entornos

## 8. Política de Tests Flaky

### Definición

Un test es flaky si pasa y falla con el mismo código en más del 5% de las ejecuciones durante 7 días.

### Proceso

1. Test flaky detectado → se etiqueta con `@flaky` en el código
2. Notificación al responsable del test en Slack
3. El responsable tiene 3 días laborables para arreglarlo o ponerlo en cuarentena
4. Los tests en cuarentena pasan a una suite separada que no bloquea CI
5. Los tests en cuarentena deben arreglarse en 1 sprint o eliminarse
6. La tasa de tests flaky se mide como métrica de calidad (objetivo: < 1%)

## 9. Métricas de Calidad

| Métrica | Objetivo | Frecuencia | Responsable |
|---------|----------|------------|-------------|
| Cobertura de tests unitarios | >= 80% | Por build | Equipo dev |
| Cobertura de tests de integración | >= 70% | Por build | Equipo dev |
| Cobertura de rutas críticas | >= 95% | Semanal | QA |
| Tasa de tests flaky | < 1% | Diaria | Equipo dev |
| Tasa de bugs que escapan | < 5 por sprint | Por sprint | QA |
| Tiempo medio de detección (MTTD) | < 1 hora | Por incidente | SRE |
| Tiempo medio de reparación (MTTR) | < 4 horas | Por incidente | Equipo dev |
| Tasa de éxito de E2E | >= 95% | Diaria | QA |

## 10. Pruebas Basadas en Riesgo

| Riesgo | Probabilidad | Impacto | Mitigación |
|--------|-------------|---------|------------|
| Falla la integración de pagos | Baja | Crítico | Contract tests + integration tests + validación en staging |
| Caso borde de expiración del token de auth | Media | Alto | Tests unitarios de la lógica de refresh |
| Fallo en migración de base de datos | Media | Alto | Tests de migración en CI + dry run en staging |
| Caída de API de terceros | Media | Medio | Circuit breaker + tests de fallback |
| Pico de carga en el lanzamiento | Alta | Medio | Tests de carga + validación de autoscaling |

## 11. Roles y Responsabilidades

| Rol | Responsabilidad |
|-----|-----------------|
| Developer | Escribir y mantener tests unitarios y de integración |
| QA Engineer | Escribir y mantener tests E2E, pruebas exploratorias |
| SRE | Mantener entornos de prueba, infraestructura de load tests |
| Tech Lead | Revisar la estrategia, aprobar excepciones de cobertura |
| Product Manager | Definir criterios de aceptación de la cobertura |

## 12. Ciclo de Revisión

- Estrategia revisada trimestralmente
- Objetivos de cobertura ajustados según datos de defectos
- Herramientas evaluadas anualmente o cuando surgen problemas
- Los hallazgos de postmortems se incorporan a la estrategia

Explanation

Trata este documento como un artefacto vivo, no como una entrega única. Revísalo cada trimestre y siempre que cambie el contexto del equipo: una herramienta nueva, un área de producto nueva, un perfil de riesgo distinto. La pirámide 70/20/7/3 es un punto de partida, no un dogma: un procesador de pagos necesita una capa de integración más gruesa porque la mayoría de los bugs viven entre componentes, mientras que una app de consumo muy centrada en UI puede justificar más cobertura E2E. El “testing trophy” de Kent C. Dodds va más allá y propone hacer de la integración la capa más grande directamente — vale la pena leerlo antes de fijar tu reparto.

Los gates de CI/CD son los que cargan con el peso del documento. Son la diferencia entre una estrategia que se aplica y una que se ignora: si nada bloquea un merge cuando baja la cobertura, la cobertura va a bajar. Conecta los umbrales al CI para que el gate falle solo; una política que depende de que alguien se acuerde de mirar un dashboard no sobrevive a un deadline.

How to Adapt This Template

No rellenes el documento de arriba abajo. Trabájalo en este orden:

1. Empieza por la tabla de alcance (sección 3). Es la conversación más difícil — qué áreas reciben 95% de cobertura y cuáles 50% — y obliga a que el debate de prioridades ocurra explícitamente en vez de quedar implícito en el code review. Junta al tech lead y al product manager para esta.
2. Ajusta la pirámide a tu dominio. Conserva los nombres de las capas, cambia los porcentajes. Deja por escrito por qué te desvías del valor por defecto en la justificación: ese razonamiento es lo que hace rápida la siguiente revisión trimestral.
3. Define gates que realmente puedas aplicar. Un gate de 90% de cobertura que tu CI no puede medir es peor que uno de 80% que corre en cada PR. Comprueba qué puede reportar tu herramienta de cobertura antes de comprometerte con números, y elige timeouts acordes a tu suite actual con margen, no a la suite que te gustaría tener.
4. Rellena la tabla de roles con nombres reales, o al menos roles reales. “QA es dueño de E2E” solo funciona si tienes QA. Un equipo de cuatro sin tester dedicado debería asignar E2E y exploratoria a desarrolladores rotados — y decirlo.
5. Deja la tabla de riesgos para el final. Los riesgos se ordenan más fácil cuando alcance y gates ya son concretos; detectarás los huecos (una dependencia externa sin probar, una ruta de migración sin cubrir) mientras rellenas las secciones anteriores.

Dos números suelen generar más debate, así que decídelos al final: el umbral de tests flaky y el timeout del pipeline de PR. Fijar el límite de flaky en 5% reconoce que los tests de sistemas distribuidos fallan de vez en cuando sin motivo; fijarlo en 1% convierte cada fallo transitorio en un incidente. La misma lógica aplica al gate de 10 minutos del PR: sácalo de los tiempos medidos de tu suite, no de lo que suene bien, y añade un margen del 25% para el crecimiento de la suite.

Reserva una sola sesión de trabajo para el borrador — una hora con quien lidere la calidad — y luego circúlalo para revisión asíncrona. El repositorio complementario tiene esta plantilla como archivo descargable más el ejemplo de pagos ya rellenado, listo para copiar. Los casos de prueba individuales que surjan de la sección 3 encajan de forma natural con la Plantilla de Caso de Prueba, y la capa de integración se conecta con los patrones de la receta de Integration Testing.

Escenario detallado: estrategia de pruebas para un microservicio de pagos

Servicio: payments-service
Equipo: 4 backend devs, 1 QA, 1 SRE
Stack: Node.js, PostgreSQL, RabbitMQ, Stripe API

Pirámide de pruebas:
  Unit: 75% (120 tests, < 20s)
    - Lógica de cálculo de totales, impuestos, descuentos
    - Validación de esquemas de request
    - Máquina de estados del pedido (pending -> paid -> refunded)
    - Helpers de formato de moneda y redondeo

  Integration: 18% (28 tests, < 4min)
    - POST /payments con PostgreSQL real (Testcontainers)
    - Webhook de Stripe con firma HMAC válida e inválida
    - Publicación de eventos en RabbitMQ
    - Idempotencia: el mismo payment_intent_id no crea doble cargo

  E2E: 5% (8 tests, < 10min)
    - Flujo completo: crear pedido -> pagar -> confirmar -> reembolsar
    - Flujo de error: pago rechazado -> notificación al usuario
    - Concurrencia: dos pagos simultáneos del mismo pedido

  Contract: 2% (4 tests, < 30s)
    - Contrato con orders-service (consumidor)
    - Contrato con notifications-service (consumidor)

Gates de CI/CD:
  Pre-commit: lint + type check (15s)
    Gate: 0 errores
  Build de PR: unit + integration + contract (5min)
    Gate: 100% pass, cobertura >= 90% (pagos es crítico)
    Gate: sin tests flaky nuevos
  Nightly: E2E + baseline de carga (25min)
    Gate: 95% pass, p95 < 300ms, sin memory leaks
  Pre-release: carga completa + soak (60min)
    Gate: 100% pass, SLOs cumplidos, sin errores 5xx

Riesgos específicos:
  | Riesgo | Probabilidad | Impacto | Mitigación |
  |--------|-------------|---------|------------|
  | Stripe cambia la API | Baja | Crítico | Contract tests con sandbox de Stripe |
  | Webhook perdido | Media | Alto | Retry + reconciliación nocturna |
  | Doble pago por retry | Media | Crítico | Idempotency key + constraint único en BD |
  | Race condition en stock | Alta | Alto | SELECT FOR UPDATE en transacción |

Datos de prueba:
  - Factory: createPayment(), createRefund(), createWebhookEvent()
  - Sandbox de Stripe: claves de test, tarjetas 4242, 4000, etc.
  - BD: PostgreSQL en Testcontainer, datos aislados por test
  - RabbitMQ: instancia en memoria o Testcontainer

Métricas seguidas:
  - Cobertura: 90% líneas, 85% ramas (más alto que el objetivo general)
  - Tasa de bugs que escapan: < 2 por sprint (pagos es crítico)
  - Latencia p95: < 300ms en baseline
  - Tasa de tests flaky: < 0.5% (más estricta que la general)

Fíjate en cómo el equipo de pagos se desvía de la plantilla por defecto allí donde está justificado: gates de cobertura más estrictos (90% frente a 80%), tolerancia flaky reducida a la mitad y los contract tests con su propia porción de la pirámide porque el servicio depende de dos consumidores más Stripe. Es el proceso de adaptación de la sección anterior aplicado a un servicio con forma real.

Variants

El mismo esqueleto se adapta a contextos muy distintos — cambia el énfasis, no la estructura:

Contexto	Enfoque	Notas
Startup / MVP	Centrarse en unit + integration, sin E2E	Velocidad por encima de cobertura
Industria regulada (FDA, SOC 2)	Añadir matriz de trazabilidad	Cada requisito mapea a tests
Microservicios	Contract tests entre servicios	Pact o Spring Cloud Contract
Código legacy	Characterization tests antes de refactorizar	Congelar el comportamiento actual
App móvil	Pruebas en device farm	BrowserStack o AWS Device Farm

What Works

1. Trata la estrategia de pruebas como un documento vivo: revísala cada trimestre
2. Aplica los gates de cobertura en CI, no mediante revisión manual
3. Mide la tasa de tests flaky como métrica de calidad de primer nivel
4. Usa pruebas basadas en riesgo para priorizar dónde importa la cobertura
5. Mantén los entornos lo más parecidos a producción posible
6. Facilita la creación de datos de prueba con factory functions
7. Separa los tests flaky de la suite principal para mantener el CI en verde

Common Mistakes

1. Escribir la estrategia una vez y no actualizarla nunca
2. Fijar umbrales de cobertura sin aplicarlos en CI
3. Ignorar los tests flaky hasta que hacen el CI poco fiable
4. Probarlo todo a nivel E2E porque “prueba lo real”
5. Usar datos de producción en entornos de prueba sin anonimizar
6. No reservar tiempo para mantenimiento de tests junto al desarrollo de funcionalidades
7. No documentar los entornos de prueba, lo que acaba en “en mi máquina funciona”

Troubleshooting

• Tests flaky: aísla el estado compartido, el tiempo y la aleatoriedad. Haz los tests independientes y deterministas; pon en cuarentena los que sigan fallando de forma intermitente.
• Alta cobertura pero bugs en producción: la cobertura no garantiza corrección. Añade mutation testing, property-based tests o contract tests.
• Suite de tests lenta: paraleliza, mockea las dependencias lentas y evita tests end-to-end para lógica que puede probarse a nivel unitario.
• Los tests pasan en local pero fallan en CI: revisa diferencias de entorno, zona horaria, locale y versiones de dependencias — y fija las versiones de las herramientas.
• Depurar un test de integración que falla: registra los payloads de request/response contra una base de datos de pruebas dedicada, y resetea el estado antes de cada test para que el fallo se reproduzca.

Further Reading

• The Practical Test Pyramid — Martin Fowler — la referencia canónica detrás de las proporciones por capas de esta plantilla
• Recursos complementarios — plantilla descargable y ejemplo rellenado de un servicio de pagos