Publicado originalmente en maturitylab.com. Este texto forma parte de la ruta Madurez.
Un modelo de madurez de pruebas describe, por niveles, la evolución del proceso de pruebas de software de una organización: desde la prueba hecha por iniciativa individual, sin plan, hasta el proceso medido y mejorado de forma continua. El modelo sirve para dos fines. Primero, muestra el nivel actual con base en evidencia. Segundo, indica el siguiente escalón y las prácticas que faltan para alcanzarlo. Este artículo presenta el modelo más usado en el mercado, las señales de cada nivel y un paso a paso para hacer el diagnóstico.
Qué evalúa un modelo de madurez de pruebas
El modelo no evalúa la calidad de un sistema concreto ni la competencia de un probador. Evalúa el proceso de pruebas: cómo la organización planifica, diseña, ejecuta, mide y mejora las pruebas en todos los proyectos.
La diferencia es relevante. Un equipo con buenos profesionales puede entregar un sistema estable y, aun así, operar en un nivel bajo de madurez, porque el resultado depende de personas y no de un proceso repetible. Cuando esas personas se van, el resultado se va con ellas.
Los modelos de madurez siguen la misma lógica de escalones que usa CMMI para los procesos de desarrollo y que usan los modelos de madurez en gestión para la empresa en su conjunto.
Los niveles de TMMi
TMMi (Test Maturity Model integration) lo mantiene la TMMi Foundation. El modelo organiza la evolución en cinco niveles. La fundación describe el punto de partida como prueba “ad hoc y no gestionada” y nombra los cuatro niveles siguientes (tmmi.org):
| Nivel | Nombre | Qué caracteriza el nivel |
|---|---|---|
| 1 | Punto de partida | Prueba sin proceso definido; el resultado depende del esfuerzo individual |
| 2 | Gestionado | Política, estrategia y plan de pruebas por proyecto; seguimiento del avance |
| 3 | Definido | Proceso de pruebas estandarizado en la organización e integrado en el ciclo de desarrollo |
| 4 | Medido | Indicadores de prueba y de calidad del producto usados para decidir |
| 5 | Optimización | Prevención de defectos y mejora continua del propio proceso de pruebas |
Cada nivel presupone el anterior. Una organización no alcanza el nivel 4 midiendo defectos si aún no tiene un proceso estandarizado que genere datos comparables entre proyectos.
¿Sabía que? Existe una norma internacional con un modelo de evaluación del proceso de pruebas: la ISO/IEC 33063:2015, que interpreta los procesos de prueba definidos en la ISO/IEC/IEEE 29119-2:2021. La propia ISO informa de que la edición de 2015 está en revisión (iso.org).
Señales que indican el nivel actual
Antes de cualquier cuestionario, algunas señales observables ya indican el nivel probable:
- Señales de nivel 1: la prueba ocurre al final del proyecto, cuando sobra tiempo; no existe plan escrito; el criterio de liberación es “nadie encontró errores”.
- Señales de nivel 2: cada proyecto tiene plan y calendario de pruebas; el responsable sabe cuántos casos se ejecutaron y cuántos fallaron; aun así, cada proyecto prueba a su manera.
- Señales de nivel 3: existe un proceso único de pruebas, con plantillas de documentos y roles definidos; la prueba empieza junto con los requisitos; las revisiones entre pares forman parte de la rutina.
- Señales de nivel 4 y 5: la organización mide densidad de defectos, cobertura y eficacia de las pruebas; usa los números para decidir dónde invertir; analiza la causa de los defectos para evitar que se repitan.
La automatización de pruebas no define el nivel. Una batería automatizada sin estrategia, sin criterio de cobertura y sin uso de los resultados mantiene a la organización en el nivel en que estaba, solo que más rápido.
Cómo hacer el diagnóstico de madurez de pruebas
El diagnóstico convierte la percepción del equipo en una nota por dimensión y en un plan de acción. La guía siguiente cabe en dos o tres semanas para un área de desarrollo de tamaño medio.
En la práctica: 6 pasos para el diagnóstico
- Definir el alcance. Elegir el área, los productos y los proyectos evaluados. Un diagnóstico de toda la empresa en la primera ronda suele generar una media sin utilidad.
- Definir las dimensiones. Usar las dimensiones del modelo de referencia: política y estrategia, planificación, diseño y ejecución, entorno de pruebas, organización y formación, medición y mejora.
- Recoger respuestas de roles distintos. Probadores, desarrolladores, responsables de producto y directivos responden al mismo cuestionario. La divergencia entre roles es un hallazgo en sí mismo.
- Exigir evidencia. Cada respuesta “sí” señala un documento, un panel o un registro. Sin evidencia, la práctica cuenta como no implantada.
- Calcular la nota por dimensión. El nivel global queda limitado por la dimensión más débil. Una organización con medición avanzada y sin plan de pruebas sigue en el nivel 1.
- Elaborar el plan del siguiente nivel. Seleccionar de tres a cinco prácticas del escalón siguiente, con responsable y plazo, y repetir el diagnóstico en seis a doce meses.
Errores comunes al adoptar el modelo
El primer error es tratar el nivel como meta de marketing. Cuando la meta es “llegar al nivel 3”, el equipo produce documentos para la evaluación y mantiene la práctica antigua. La meta útil es el efecto del nivel: menos defectos en producción, fechas de liberación previsibles y decisiones de liberación basadas en datos.
El segundo error es saltarse escalones. Implantar indicadores de nivel 4 sin un proceso estandarizado genera números que no se pueden comparar entre proyectos.
El tercer error es evaluar el proceso de pruebas aislado de la gestión. La prueba depende de requisitos claros, de entornos disponibles y de prioridades definidas por la dirección. Cuando el diagnóstico de pruebas señala carencias en esos puntos, la causa está en la gestión, y un diagnóstico de madurez empresarial ayuda a localizar el origen.
Preguntas frecuentes
¿TMMi sustituye a CMMI?
No. CMMI trata los procesos de desarrollo y de gestión de forma amplia. TMMi profundiza en el proceso de pruebas. Las organizaciones que ya usan CMMI pueden usar TMMi para detallar la verificación y la validación.
¿Se puede usar el modelo en equipos ágiles?
Sí. El modelo describe lo que debe existir, como estrategia, planificación y medición, y no impone un ciclo de vida. En equipos ágiles, el plan de pruebas puede ser la estrategia del sprint y la medición puede venir del pipeline de integración continua.
¿La evaluación necesita certificación formal?
No para uso interno. Un diagnóstico con cuestionario y evidencia ya muestra el nivel y el plan de acción. La evaluación formal, realizada por un evaluador acreditado, solo es necesaria cuando la organización quiere un reconocimiento público de su nivel.
