Estrategia vs Plan: Por Qué la Distinción Importa
Una de las confusiones más comunes en QA es la diferencia entre estrategia y plan de testing. Muchos equipos usan los términos indistintamente, pero sirven propósitos diferentes.
Estrategia de Testing
Una estrategia de testing es un documento a nivel organizacional que define el enfoque general de testing entre proyectos y equipos. Es de largo plazo, reutilizable y raramente cambia.
Qué Contiene
- Enfoque de testing: Tipos de testing que realiza la organización
- Niveles de testing: Unit, integración, sistema, aceptación — cuáles son obligatorios
- Política de automatización: Qué automatizar, herramientas aprobadas, metas de cobertura
- Estándares de herramientas: Herramientas aprobadas de gestión, automatización y monitoreo
- Estrategia de entornos: Cómo se aprovisionan y gestionan
- Proceso de gestión de defectos: Clasificación de severidad, proceso de triage, SLAs
- Métricas y reportes: Qué se rastrea, cómo se generan reportes
- Roles y responsabilidades: Roles QA estándar y su alcance
- Gestión de riesgos: Cómo se identifican y mitigan riesgos
- Requisitos de compliance: Estándares de la industria (HIPAA, PCI-DSS, SOX)
Estrategia por Tamaño de Empresa
Startup (5-20 personas): Informal, 1-2 páginas. Foco en qué automatizar primero y estándares mínimos de calidad.
Empresa mediana (50-200): Estructurada, 5-10 páginas. Estandarización entre equipos, herramientas compartidas.
Empresa grande (500+): Comprensiva, 15-30+ páginas. Gobernanza, compliance, coordinación entre equipos.
Plan de Testing
Un plan de testing es un documento específico del proyecto que describe alcance, enfoque, recursos y cronograma para un proyecto o release particular.
Estructura IEEE 829
- Identificador del plan
- Referencias: Documentos relacionados
- Introducción: Propósito y alcance
- Items de testing: Qué software/features se probarán
- Riesgos de software
- Features a probar
- Features que no se probarán (y por qué)
- Enfoque: Métodos y técnicas
- Criterios de pass/fail
- Criterios de suspensión y reanudación
- Entregables de testing
- Tareas restantes
- Necesidades de entorno
- Necesidades de personal y capacitación
- Responsabilidades
- Cronograma
- Riesgos del plan y contingencias
- Aprobaciones
Comparación Lado a Lado
| Aspecto | Estrategia de Testing | Plan de Testing |
|---|---|---|
| Nivel | Organización | Proyecto |
| Duración | Años | Semanas/meses |
| Autor | Liderazgo QA | QA lead del proyecto |
| Cambios | Raramente | Por proyecto |
| Especificidad | Enfoque general | Alcance, cronograma, recursos específicos |
| Aprobación | Gerencia QA | Stakeholders del proyecto |
Cómo Trabajan Juntos
Organizacional] --> TP1[Plan de Testing
Proyecto A] TS --> TP2[Plan de Testing
Proyecto B] TS --> TP3[Plan de Testing
Proyecto C] style TS fill:#2196F3,color:#fff style TP1 fill:#4CAF50,color:#fff style TP2 fill:#4CAF50,color:#fff style TP3 fill:#4CAF50,color:#fff
La estrategia proporciona el marco. El plan aplica ese marco a un proyecto específico.
Cuándo Necesitas Cada Documento
| Situación | Lo Que Necesitas |
|---|---|
| Nuevo equipo QA formándose | Estrategia primero |
| Nuevo proyecto comenzando | Plan (siguiendo estrategia existente) |
| Auditoría o revisión de compliance | Ambos |
| Adopción de nueva herramienta | Actualizar estrategia |
| Planificación de sprint | Plan ligero o sección de testing |
| Release mayor | Plan detallado |
Ejercicio: Escribir un Esquema de Estrategia de Testing
Has sido contratado como QA Lead para una startup fintech de 30 empleados. La empresa construye una app de pagos móviles. Actualmente:
- 3 ingenieros QA (todos testers manuales)
- Sin proceso formal de testing ni documentación
- Desarrolladores escriben algunos unit tests inconsistentemente
- Testing ocurre ad-hoc antes de cada release
- La app maneja transacciones financieras (requiere PCI-DSS)
Tu tarea:
Escribe un esquema de estrategia que cubra:
- Enfoque de testing y niveles
- Política de automatización (qué automatizar primero, herramientas, cronograma)
- Estándares de herramientas
- Proceso de gestión de defectos
- Requisitos de compliance (PCI-DSS)
- Métricas a rastrear
- Roadmap de 6 meses para implementar la estrategia
Pista
PCI-DSS requiere testing de seguridad, controles de acceso y logging de auditoría. Comienza la automatización con tests de mayor ROI (API, smoke). Con solo 3 QA, la estrategia debe ser práctica.
Solución de Ejemplo
Estrategia de Testing para FinPay
1. Niveles de Testing:
| Nivel | Responsable | Requisito Mínimo |
|---|---|---|
| Unit tests | Desarrolladores | 70% cobertura para código nuevo, obligatorio para lógica de pagos |
| Integración | Dev + QA | Contract tests de API para todos los servicios |
| Sistema | QA | Funcional, seguridad, rendimiento por release |
| Aceptación | QA + Producto | UAT para features mayores |
2. Automatización (Prioridad):
- Tests de API para flujos de pago (Mes 1-2)
- Smoke tests para app móvil (Mes 2-3)
- Suite de regresión para flujos core (Mes 3-4)
- Tests de rendimiento (Mes 4-5)
Meta: 60% cobertura automatizada al mes 6.
3. Herramientas: TestRail (gestión), Playwright + Appium (automatización), k6 (rendimiento), OWASP ZAP (seguridad), GitHub Actions (CI/CD), Jira (bugs).
4. Gestión de Defectos:
- Crítico: Fallas de pago, pérdida de datos — Fix en 4 horas
- Alto: Feature core roto — Fix en 24 horas
- Medio: Feature no-core — Fix en sprint actual
- Bajo: Cosmético — Fix cuando haya capacidad
5. PCI-DSS:
- Escaneos de seguridad automatizados trimestrales
- Penetration testing anual (proveedor externo)
- Datos de pago encriptados en tránsito y reposo — verificado en cada release
- Sin datos reales de tarjetas en entornos de prueba
6. Métricas:
- Tasa de defectos escapados: < 5 bugs críticos/trimestre en producción
- Cobertura de automatización: 60% al mes 6
- Tiempo de ejecución de regresión: < 30 minutos
- Score de compliance PCI-DSS: 100%
7. Roadmap:
| Mes | Foco | Entregables |
|---|---|---|
| 1 | Fundación | Estrategia aprobada, TestRail configurado, proceso de defectos |
| 2 | Automatización API | API de pagos automatizada, integración CI/CD |
| 3 | Automatización móvil | Smoke tests iOS/Android, suite de regresión iniciada |
| 4 | Rendimiento | Tests k6, baseline, primer escaneo PCI-DSS |
| 5 | Madurez | Suite completa automatizada, dashboard de métricas |
| 6 | Optimización | 60% automatización, primera auditoría trimestral |
Consejos Pro
Comienza con la estrategia. Si tu organización no tiene una, créala antes de escribir planes de proyecto.
Mantén los planes como documentos vivos. Un plan escrito al inicio y nunca actualizado es ficción a mitad del proyecto.
Incluye lo que NO pruebas. La sección “fuera de alcance” es tan importante como “en alcance.”
Obtén buy-in de stakeholders en criterios. Si el PM acepta que “cero bugs críticos” es criterio de salida, no puede presionarte para liberar con bugs críticos.
Usa plantillas, pero personaliza. IEEE 829 es buen punto de partida, pero adáptalo a tu equipo y proyecto.