Introducción
La madurez QA de un equipo no se mide en número de tests ni en porcentaje de cobertura. Se mide en la capacidad del proceso de calidad para prevenir que los problemas lleguen a producción de forma sistemática, no por suerte.
El diagnóstico de madurez QA es el punto de partida para mejorar un proceso de calidad: sin saber dónde está el equipo hoy, cualquier acción de mejora puede ser bien intencionada pero mal dirigida. Este artículo explica los 4 niveles de madurez y cómo identificar en cuál está tu equipo.
¿Qué es la madurez QA?
La madurez QA es el grado en que el proceso de calidad de software de una organización está definido, medido, controlado y mejorado de forma sistemática. Un proceso maduro es predecible: produce resultados consistentes independientemente de quién lo ejecuta y en qué momento del proyecto.
Los marcos de referencia más usados para modelar la madurez QA son:
- TMMi (Test Maturity Model Integration): el estándar más específico para testing, con 5 niveles de madurez desde el más básico (ad hoc) hasta el más avanzado (optimizado)
- ISO/IEC 33063: el estándar internacional de procesos de evaluación del software, que incluye criterios para evaluar la madurez del proceso de testing
- Modelos propios de consultoras especializadas: versiones simplificadas que adaptan los marcos anteriores a la realidad de equipos pequeños y medianos
Para equipos de 20-200 empleados con equipos de desarrollo activos, un modelo de 4 niveles es más práctico que los 5 niveles del TMMi sin perder precisión diagnóstica.
Los 4 niveles de madurez QA
Nivel 1: Inicial (Reactivo)
El testing existe, pero no como proceso — como reacción. Se prueba cuando hay tiempo, se testea lo que a alguien le parece importante y la estrategia de testing depende de quién esté disponible ese sprint.
Señales de que el equipo está en nivel 1:
- No hay una estrategia de testing documentada — las decisiones se toman implícitamente
- Los bugs se encuentran principalmente en producción, reportados por usuarios
- El QA es la última fase antes del deploy y la primera que se recorta cuando hay presión de tiempo
- No hay métricas de calidad — nadie sabe cuántos bugs se producen por sprint ni cuántos llegan a producción
- El equipo de desarrollo y el de QA trabajan en silos, sin colaboración en la definición de requisitos
Nivel 2: Básico (Controlado)
El testing está planificado y documentado. Hay criterios de aceptación definidos, casos de prueba escritos y un proceso de reporte de defectos. La cobertura es principalmente manual y reactiva, pero hay consistencia básica.
Señales de nivel 2:
- Hay planes de prueba documentados para las funcionalidades principales
- Los defectos se registran en una herramienta (Jira, Azure DevOps, o similar)
- Hay criterios de aceptación para las historias de usuario, aunque no siempre sean completos
- Se hace testing de regresión manual antes de cada release, aunque tome mucho tiempo
- Hay algo de automatización, pero no está integrada en el pipeline CI/CD
Nivel 3: Intermedio (Colaborativo)
El QA está integrado en el ciclo de desarrollo, no es una fase separada al final. El equipo de QA participa en el refinamiento de historias, la automatización corre en el pipeline y hay métricas de calidad que se revisan regularmente.
Señales de nivel 3:
- QA participa en las sesiones de refinamiento y planning — no solo en el testing
- La automatización de regresión corre automáticamente en el pipeline CI/CD
- Hay métricas de calidad revisadas regularmente: tasa de defectos, cobertura, tiempo de corrección
- La Definition of Done incluye criterios de calidad verificados por QA
- Los tipos de testing no funcional (rendimiento, seguridad, accesibilidad) tienen cobertura básica
Nivel 4: Avanzado (Preventivo y Optimizado)
El proceso de calidad es preventivo: los problemas se detectan en las fases más tempranas del ciclo, la automatización cubre los flujos críticos y el equipo usa métricas de calidad para tomar decisiones de ingeniería, no solo para reportar.
Señales de nivel 4:
- QA revisa los requisitos antes de que empiece el desarrollo — el shift-left está implementado
- El pipeline de CI/CD tiene quality gates que bloquean el deploy si los tests críticos fallan
- Hay análisis de causa raíz sistemático de los bugs que llegan a producción
- Las métricas de calidad se usan para tomar decisiones: si la tasa de defectos sube, se ajusta el proceso
- La estrategia de testing se revisa y ajusta regularmente en función de los datos
¿Cómo se evalúa la madurez QA en las 5 dimensiones?
Un diagnóstico de madurez QA riguroso evalúa el proceso en 5 dimensiones, no solo en la ejecución de tests:
| Dimensión | Qué se evalúa |
|---|---|
| Procesos | Si los procesos de testing están definidos, documentados y se siguen de forma consistente — no dependen de que la persona correcta esté disponible |
| Automatización | Qué está automatizado, si los tests automáticos están integrados en el pipeline y si el equipo puede mantenerlos |
| Cultura | Si el equipo de desarrollo asume responsabilidad sobre la calidad o la delega completamente al equipo de QA |
| Métricas | Si hay indicadores de calidad definidos y si alguien los usa para tomar decisiones de proceso |
| Herramientas | Si el stack tecnológico soporta las prácticas de testing o las limita |
¿Por qué es útil saber el nivel de madurez QA del equipo?
Porque las acciones de mejora efectivas dependen del punto de partida. Un equipo en nivel 1 que intenta implementar prácticas de nivel 4 directamente fracasa — no por falta de capacidad, sino porque se saltó los fundamentos que hacen que las prácticas avanzadas funcionen.
El diagnóstico de madurez QA sirve para:
- Identificar el cuello de botella real — qué está fallando específicamente, no en general
- Priorizar las acciones de mejora por impacto — qué da más resultado con el esfuerzo disponible
- Establecer un baseline medible — saber de dónde se parte para poder medir si se está mejorando
- Comunicar el estado de calidad a la dirección en términos comprensibles — no en métricas técnicas, sino en niveles de madurez con descripción clara
Para equipos que están evaluando externalizar QA, el diagnóstico también sirve para entender qué capacidades tiene el equipo interno y cuáles complementa una consultora externa.