RTM en QA: matriz de trazabilidad de requisitos

Matriz de Trazabilidad de Requisitos: Estructura y Aplicación en QA

La Matriz de Trazabilidad de Requisitos (RTM) es una tabla que documenta las relaciones entre requisitos, casos de prueba y defectos a lo largo de todas las etapas del ciclo de vida del software. Proporciona respuestas a preguntas clave: qué se ha probado, qué queda sin cubrir y por qué se realiza una prueba específica.

Sin una RTM, las pruebas pierden transparencia; con ella, las pruebas se convierten en un proceso medible con métricas de cobertura claras.

Objetivos del Uso de la Matriz

La RTM aborda las siguientes tareas:

• Evaluar la completitud de la cobertura de requisitos por pruebas.
• Identificar lagunas en la documentación de pruebas.
• Analizar el impacto de los cambios en los requisitos sobre las pruebas existentes.
• Rastrear la ruta desde el requisito hasta el defecto.
• Generar informes para las partes interesadas con indicadores cuantitativos.

Estas funciones hacen que la RTM sea indispensable en proyectos medianos y grandes con requisitos extensos.

Tipos de Trazabilidad en la RTM

Existen diferentes enfoques para construir relaciones:

| Tipo | Dirección del Enlace | Aplicación |

|------|-------------------|-------------|

| Hacia adelante | Requisito → Caso de Prueba | Verificar que existen pruebas para un requisito |

| Hacia atrás | Caso de Prueba → Requisito | Justificar la necesidad de una prueba |

| Bidireccional | Requisito ⇄ Caso de Prueba | Control completo en ambas direcciones |

| Vertical | Requisito → Diseño → Código → Prueba | Trazabilidad de extremo a extremo entre etapas |

| Horizontal | Prueba → Error → Corrección → Reprueba | Trazabilidad dentro de las pruebas |

La elección del tipo depende de la complejidad del proyecto y la etapa de desarrollo.

Estructura de Columnas en la Tabla RTM

Una matriz estándar incluye los siguientes campos:

• ID del Requisito — identificador único (REQ-AUTH-01).
• Descripción del Requisito — descripción breve (autorización por correo).
• ID del Caso de Prueba — lista de casos de prueba relacionados (TC-LOGIN-01, TC-LOGIN-02).
• Estado de la Prueba — estado de ejecución (Aprobado/Fallido/Bloqueado/No Ejecutado).
• ID del Defecto — identificadores de defectos (BUG-101).
• Estado del Defecto — estado del error (Abierto/Corregido/Cerrado).
• Estado de Cobertura — estado de cobertura (Cubierto/No Cubierto/Parcial).
• % de Cobertura — porcentaje de cobertura (100%/0%/50%).

Ejemplos de Tablas RTM

Tabla Básica (Requisitos y Casos de Prueba)

| ID REQ | Requisito | Prioridad | ID Caso de Prueba | Estado de Prueba | ID Defecto | % Cobertura |

|--------|-------------|----------|--------------|-------------|-----------|------------|

| REQ-01 | Autorización | Alta | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Aprobado, Aprobado, Fallido | BUG-101 | 100% |

| REQ-02 | Recuperación de Contraseña | Media | TC-REC-01, TC-REC-02 | Aprobado, No Ejecutado | — | 50% |

| REQ-04 | Filtrado de Precios | Baja | — | — | — | 0% |

Tabla Extendida con Enlaces de Desarrollo

| ID REQ | Requisito | ID Caso de Prueba | Resultado | ID Defecto | Tarea Dev | Componente |

|--------|-------------|--------------|--------|-----------|----------|-----------|

| REQ-01 | Inicio de Sesión | TC-AUTH-01 | ✅ Aprobado | — | TAREA-101 | Módulo de Autenticación |

| REQ-01 | Inicio de Sesión | TC-AUTH-03 | ❌ Fallido | BUG-001 | TAREA-101 | Módulo de Autenticación |

Estas tablas permiten una localización rápida de áreas problemáticas.

Esquemas de Trazabilidad Textual

Enlace Clásico Hacia Adelante

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ REQUISITO    │      │ CASO DE PRUEBA│      │   DEFECTO    │
│ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101      │
└──────────────┘      └──────────────┘      └──────────────┘

Trazabilidad Vertical de Extremo a Extremo

┌─────────────────────┐
│  REQUISITO DE NEGOCIO│
└──────────┬──────────┘
           ▼
┌─────────────────────┐    ┌─────────────┐
│  REQUISITOS         │───▶│   CASOS     │
│   FUNCIONALES       │    │   DE PRUEBA │
└──────────┬──────────┘    └──────┬──────┘
           │                     │
           ▼                     ▼
┌─────────┐              ┌─────────────────────┐
│TAREAS   │              │  EJECUCIÓN DE       │
│TÉCNICAS │              │   PRUEBAS           │
└────┬────┘              └──────────┬──────────┘
     │                             │
     ▼                             ▼
┌─────────────────────┐    ┌─────────────────────┐
│      DEFECTOS       │    │      DEFECTOS       │
└─────────────────────┘    └─────────────────────┘

Análisis de Estadísticas de Cobertura

Un informe típico de RTM incluye:

| Métrica | Valor | Fórmula |

|--------|-------|---------|

| Total de Requisitos | 50 | — |

| Con Pruebas | 45 | — |

| Sin Pruebas | 5 | — |

| % de Cobertura | 90% | (45/50)×100% |

| Pruebas por Requisito (prom.) | 3.6 | 180/50 |

Errores comunes: matriz desactualizada, enlaces formales, falta de enlaces a defectos, pruebas duplicadas.

Lista de Verificación para Ingenieros de QA

• Cada requisito tiene al menos un caso de prueba.
• No hay casos de prueba "huérfanos" sin enlaces.
• Las pruebas relacionadas se actualizan cuando cambian los requisitos.
• Cada defecto está vinculado a un requisito.
• La matriz se actualiza después de cada sprint/lanzamiento.
• Es posible analizar las causas de fallos mediante la RTM.

Herramientas de Automatización de RTM

| Herramienta | Tipo | Características |

|------|------|----------|

| Jira + Xray/Zephyr | Complementos | Trazabilidad ágil |

| TestRail | Gestión de Pruebas | RTM nativo |

| Qase | Gestión de Pruebas | Enlaces simples |

| Excel/Google Sheets | Manual | Para proyectos pequeños |

| Polarion/Azure DevOps | ALM | Nivel empresarial |

Cuándo Evitar la RTM

La matriz no es adecuada para:

• Proyectos con <20 requisitos.
• Equipos de <3 personas.
• Sprints cortos (1-2 semanas).
• Pruebas ad-hoc o MVPs con cambios frecuentes.

Desventajas: alto esfuerzo de actualización, riesgo de formalismo, sobrecarga para startups.

Regla: La RTM es rentable con >20 requisitos y equipos de 3+ personas.

Conclusiones Clave

• La RTM garantiza una cobertura de requisitos del 90%+ por pruebas en proyectos grandes.
• La trazabilidad bidireccional minimiza riesgos durante la regresión.
• La relevancia de la matriz es clave para su valor; actualizar después de cada cambio.
• Usar herramientas ALM para automatización a nivel empresarial.
• Analizar métricas: lagunas de cobertura y casos de prueba por requisito.

— Editorial Team