Glosario · Fundamentos de testing
Matriz de trazabilidad de requisitos
En inglés: Requirements traceability matrix
También llamado: RTM, matriz de trazabilidad, trazabilidad de requisitos, traceability matrix
Definición
Tabla que relaciona cada requisito con los casos de prueba que lo verifican y sus resultados, para que se vean los huecos de cobertura y el impacto de los cambios.
Una matriz de trazabilidad de requisitos (RTM, requirements traceability matrix) vincula los requisitos con los tests que los cubren y, a menudo, también con los resultados de ejecución y los defectos. Responde rápidamente a dos preguntas: ¿está probado cada requisito?, y si este requisito cambia, ¿qué tests hay que actualizar? Es obligatoria en sectores regulados como los dispositivos médicos, la aviación y las finanzas, y útil en cualquier lugar donde haya que demostrar cobertura.
Ejemplo
| Requisito | Descripción | Casos de prueba | Estado | Defectos |
|---|---|---|---|---|
| AUTH-01 | El usuario puede iniciar sesión con credenciales válidas | TC-101, TC-102 | Superado | ninguno |
| AUTH-02 | La cuenta se bloquea tras 5 intentos fallidos | TC-103, TC-104, TC-105 | Fallido | BUG-311 |
| AUTH-03 | El enlace de restablecimiento de contraseña caduca a los 30 minutos | (ninguno) | Sin cobertura | n/a |
Cómo leerla: AUTH-03 no tiene tests, lo que es un hueco de cobertura. AUTH-02 está cubierto pero falla, así que es un riesgo para la release ligado a un bug concreto.
Hacia delante, hacia atrás y bidireccional
- Trazabilidad hacia delante: del requisito a los tests. Demuestra que cada requisito está verificado.
- Trazabilidad hacia atrás: del test al requisito. Muestra tests que no verifican nada que alguien haya pedido, que pueden estar obsoletos o revelar un requisito que falta.
- Bidireccional: en ambos sentidos, que es lo que esperan la mayoría de los auditores.
RTM frente a cobertura de código
Una RTM mide la cobertura de requisitos: si cada necesidad declarada tiene un test. La cobertura de código mide qué líneas o ramas se ejecutaron durante los tests. Puedes tener un 100 % de cobertura de requisitos con una cobertura de código pobre, y al revés. Responden a preguntas distintas y funcionan mejor juntas.
Mantenerla al día
Una hoja de cálculo mantenida a mano se queda obsoleta enseguida. La mayoría de los equipos generan la trazabilidad desde sus herramientas: casos de prueba etiquetados con los IDs de las historias en la herramienta de gestión de pruebas, o tests automatizados anotados con la clave del requisito (por ejemplo una etiqueta como @AUTH-02 en los títulos de los tests de Playwright o un @Tag de JUnit), y después un informe los une. La matriz es tan buena como la disciplina de etiquetar cada test nuevo.