El Problema de la Cobertura
Tienes 150 requisitos y 500 test cases. ¿Cómo sabes que cada requisito está cubierto por al menos un test? ¿Cómo sabes que no hay test cases huérfanos probando funcionalidades que ya no existen? Cuando un requisito cambia, ¿qué test cases necesitan actualizarse?
Sin una forma sistemática de vincular requisitos con pruebas, estas preguntas son casi imposibles de responder. La Matriz de Trazabilidad de Requisitos (RTM) es ese vínculo sistemático.
¿Qué Es una Matriz de Trazabilidad de Requisitos?
Una RTM es un documento — típicamente una tabla u hoja de cálculo — que mapea requisitos a test cases y frecuentemente a resultados de pruebas y defectos. Crea una cadena trazable desde la necesidad de negocio hasta la verificación.
La idea clave es la trazabilidad bidireccional: puedes trazar hacia adelante desde requisitos hacia tests (¿están todos los requisitos cubiertos?) y hacia atrás desde tests hacia requisitos (¿cada test está justificado por un requisito?).
Tipos de Trazabilidad
Trazabilidad Hacia Adelante
Mapea de requisitos a test cases. Responde: “¿Se prueba cada requisito?”
| ID Requisito | Requisito | IDs de Test Cases |
|---|---|---|
| REQ-001 | El usuario puede iniciar sesión con email y contraseña | TC-101, TC-102, TC-103 |
| REQ-002 | El usuario puede restablecer contraseña por email | TC-104, TC-105 |
| REQ-003 | La sesión expira tras 30 min de inactividad | TC-106 |
| REQ-004 | El usuario puede habilitar 2FA | Ninguno |
Inmediatamente puedes ver que REQ-004 no tiene test cases — una brecha de cobertura que debe atenderse.
Trazabilidad Hacia Atrás
Mapea de test cases a requisitos. Responde: “¿Cada test está justificado?”
| ID Test Case | Test Case | ID Requisito |
|---|---|---|
| TC-101 | Login con credenciales válidas | REQ-001 |
| TC-102 | Login con contraseña inválida | REQ-001 |
| TC-103 | Login con campos vacíos | REQ-001 |
| TC-104 | Solicitar restablecimiento de contraseña | REQ-002 |
| TC-105 | Restablecer contraseña con enlace expirado | REQ-002 |
| TC-106 | Timeout de sesión por inactividad | REQ-003 |
| TC-107 | Login con caracteres especiales en usuario | Ninguno |
TC-107 no tiene un requisito vinculado — puede ser un test de caso borde válido o puede estar probando algo fuera de alcance. En cualquier caso, merece revisión.
Trazabilidad Bidireccional
Combina ambas direcciones en una sola matriz. Esta es la forma más completa y más comúnmente utilizada.
Estructura de una RTM Completa
Una RTM completa típicamente incluye estas columnas:
| Columna | Descripción | Ejemplo |
|---|---|---|
| ID Requisito | Identificador único | REQ-001 |
| Descripción del Requisito | Qué debe hacer el sistema | “El usuario puede iniciar sesión con email/contraseña” |
| Prioridad | Prioridad de negocio | Alta |
| ID(s) Test Case | Test cases vinculados | TC-101, TC-102, TC-103 |
| Estado del Test Case | Estado actual de ejecución | Pass / Fail / Not Run |
| ID(s) Defecto | Defectos encontrados | BUG-042 |
| Estado del Defecto | Estado actual del defecto | Open / Fixed / Verified |
| Comentarios | Contexto adicional | “Requiere revisión de seguridad” |
Ejemplo: RTM del Carrito de E-Commerce
Aquí hay un ejemplo realista para una funcionalidad de carrito de compras:
| ID Req | Requisito | Prioridad | Test Cases | Estado | Defectos |
|---|---|---|---|---|---|
| CART-01 | Agregar ítem al carrito | Alta | TC-201, TC-202, TC-203 | Pass, Pass, Pass | — |
| CART-02 | Actualizar cantidad del ítem | Alta | TC-204, TC-205 | Pass, Fail | BUG-089 |
| CART-03 | Eliminar ítem del carrito | Media | TC-206 | Pass | — |
| CART-04 | Aplicar código de cupón | Media | TC-207, TC-208, TC-209 | Pass, Pass, Not Run | — |
| CART-05 | Carrito persiste entre sesiones | Baja | TC-210 | Not Run | — |
| CART-06 | Mostrar estimación de envío | Media | — | — | — |
Análisis:
- CART-02 tiene un test case fallando con un defecto abierto — requiere atención
- CART-04 tiene un test case aún no ejecutado
- CART-05 no ha sido probado en absoluto
- CART-06 no tiene test cases — esta es una brecha de cobertura
Beneficios de Usar una RTM
1. Identificación de Brechas de Cobertura
Como se mostró arriba, escanear la RTM revela inmediatamente requisitos sin test cases. Sin una RTM, esta brecha podría pasar inadvertida hasta producción.
2. Análisis de Impacto
Cuando un requisito cambia, la RTM te dice exactamente qué test cases se ven afectados. Sin ella, tendrías que buscar manualmente entre cientos de test cases.
Ejemplo: Si CART-01 cambia de “agregar un solo ítem” a “agregar uno o múltiples ítems,” la RTM muestra que TC-201, TC-202 y TC-203 necesitan actualización. También podrías necesitar agregar nuevos test cases.
3. Reporte de Completitud de Testing
Project managers y stakeholders pueden ver de un vistazo:
- Qué porcentaje de requisitos tienen test cases (cobertura)
- Qué porcentaje de test cases se han ejecutado (progreso)
- Cuántos requisitos tienen tests que pasan (confianza)
4. Cumplimiento Regulatorio
En industrias reguladas (salud, finanzas, aviación), una RTM es frecuentemente obligatoria. Los auditores la usan para verificar que cada requisito regulatorio ha sido probado y verificado.
5. Detección de Scope Creep
Si descubres test cases no vinculados a ningún requisito, puede indicar funcionalidades no oficiales o scope creep que necesita discutirse con stakeholders.
Creando una RTM: Paso a Paso
Paso 1: Recopilar Requisitos
Recopila todos los requisitos de especificaciones, user stories, criterios de aceptación, documentos regulatorios y cualquier otra fuente. Asigna IDs únicos a cada uno.
Paso 2: Diseñar Test Cases
Escribe test cases que cubran cada requisito. Apunta a al menos un test case positivo y uno negativo por requisito.
Paso 3: Mapear Requisitos a Test Cases
Crea la matriz vinculando cada requisito con sus test cases. Aquí es donde se establece la trazabilidad hacia adelante.
Paso 4: Verificar Trazabilidad Hacia Atrás
Verifica que cada test case se mapee a al menos un requisito. Investiga cualquier test case huérfano.
Paso 5: Ejecutar y Actualizar
Conforme se ejecutan las pruebas, actualiza la columna de estado. Cuando se encuentran defectos, vincúlalos tanto al test case como al requisito.
Paso 6: Revisar Regularmente
Revisa la RTM en hitos clave: después del diseño de pruebas, durante la ejecución de pruebas y antes de las decisiones de release.
Herramientas para Crear RTMs
| Herramienta | Complejidad | Mejor Para |
|---|---|---|
| Hojas de cálculo (Excel, Google Sheets) | Baja | Proyectos pequeños, equipos nuevos en RTM |
| Jira + Xray / Zephyr | Media | Equipos Agile usando Jira |
| TestRail | Media | Gestión de pruebas dedicada |
| Azure DevOps Test Plans | Media | Equipos en ecosistema Microsoft |
| HP ALM / Micro Focus | Alta | Empresas, industrias reguladas |
| Doors (IBM) | Alta | Sistemas de seguridad crítica |
Para la mayoría de equipos que comienzan, una hoja de cálculo bien estructurada es perfectamente adecuada. Migra a una herramienta dedicada cuando el proyecto crezca más allá de 200-300 requisitos.
RTM en Proyectos Agile
En Agile, el concepto de RTM sigue aplicando pero se adapta a la naturaleza iterativa de los sprints:
- Requisitos = User Stories + Criterios de Aceptación
- Trazabilidad frecuentemente se mantiene en herramientas como Jira (vinculando stories a test cases)
- Alcance es por sprint en lugar de todo el proyecto
- Actualizaciones ocurren cada sprint en lugar de en hitos del proyecto
Muchos equipos Agile mantienen un mapeo ligero “story-a-test” dentro de su sprint board, logrando el mismo objetivo sin el overhead de un documento RTM formal.
Errores Comunes con RTMs
- Crearla una vez y nunca actualizarla — Una RTM es un documento vivo. RTMs desactualizadas dan falsa confianza.
- Trazabilidad demasiado granular — Trazar cada sub-requisito a cada sub-test crea overhead de mantenimiento sin beneficio proporcional.
- Sin trazabilidad hacia atrás — La trazabilidad solo hacia adelante pierde test cases huérfanos.
- Ignorar requisitos no funcionales — Performance, seguridad y accesibilidad también necesitan trazabilidad.
- No involucrar desarrolladores — Los desarrolladores pueden ayudar a identificar requisitos que necesitan más cobertura de pruebas basándose en la complejidad del código.
Ejercicio: Crea una RTM
Escenario: Estás construyendo una RTM para una funcionalidad de registro de usuario. A continuación están los requisitos y test cases. Tu tarea es crear una RTM bidireccional y analizarla en busca de brechas.
Requisitos:
| ID | Requisito |
|---|---|
| REG-01 | El usuario puede registrarse con email, contraseña y nombre |
| REG-02 | La contraseña debe tener al menos 8 caracteres con una mayúscula y un número |
| REG-03 | El sistema envía email de confirmación después del registro |
| REG-04 | El usuario no puede registrarse con un email existente |
| REG-05 | El usuario puede registrarse usando Google OAuth |
| REG-06 | Los términos y condiciones deben aceptarse antes del registro |
Test Cases:
| ID | Test Case |
|---|---|
| TC-301 | Registrarse con email, contraseña y nombre válidos |
| TC-302 | Registrarse con contraseña menor a 8 caracteres |
| TC-303 | Registrarse con contraseña sin letra mayúscula |
| TC-304 | Registrarse con contraseña sin número |
| TC-305 | Registrarse con email que ya existe |
| TC-306 | Verificar que se recibe email de confirmación |
| TC-307 | Registrarse usando cuenta de Google |
| TC-308 | Registrarse sin aceptar términos |
| TC-309 | Registrarse con campo de nombre vacío |
| TC-310 | Registrarse con inyección SQL en campo de email |
Tareas:
- Crea la RTM bidireccional (mapea requisitos a test cases Y test cases a requisitos)
- Identifica brechas de cobertura (requisitos sin tests)
- Identifica test cases huérfanos (tests sin requisitos)
- Sugiere test cases adicionales para cerrar brechas
Pista
- Mapea cada test case al requisito que verifica. Algunos test cases pueden mapearse a múltiples requisitos.
- Busca requisitos que no tengan test cases en absoluto.
- Busca test cases que no se mapeen a ningún requisito listado.
- Considera qué escenarios adicionales podría necesitar cada requisito.
Solución
RTM Bidireccional
| ID Req | Requisito | IDs Test Case | Cobertura |
|---|---|---|---|
| REG-01 | Registrarse con email, contraseña, nombre | TC-301, TC-309 | Cubierto |
| REG-02 | Requisitos de contraseña | TC-302, TC-303, TC-304 | Cubierto |
| REG-03 | Email de confirmación | TC-306 | Parcialmente cubierto |
| REG-04 | No registrarse con email existente | TC-305 | Cubierto |
| REG-05 | Registrarse con Google OAuth | TC-307 | Parcialmente cubierto |
| REG-06 | Aceptar términos antes del registro | TC-308 | Cubierto |
Trazabilidad Hacia Atrás
| ID TC | Test Case | ID Req |
|---|---|---|
| TC-301 | Registro con datos válidos | REG-01 |
| TC-302 | Contraseña muy corta | REG-02 |
| TC-303 | Contraseña sin mayúscula | REG-02 |
| TC-304 | Contraseña sin número | REG-02 |
| TC-305 | Email existente | REG-04 |
| TC-306 | Email de confirmación | REG-03 |
| TC-307 | Google OAuth | REG-05 |
| TC-308 | Términos no aceptados | REG-06 |
| TC-309 | Nombre vacío | REG-01 |
| TC-310 | Inyección SQL en email | Ninguno (huérfano) |
Análisis
Brechas de cobertura:
- REG-03 solo tiene un test case. Falta: email de confirmación no recibido, email contiene detalles correctos, el enlace de confirmación funciona.
- REG-05 solo tiene un test case. Falta: fallo de Google OAuth, cuenta de Google sin email, flujo OAuth cancelado.
Test cases huérfanos:
- TC-310 (inyección SQL) no se mapea a ningún requisito listado. Es un test de seguridad válido — debería vincularse a un requisito de seguridad implícito o explícito. Si no existe un requisito de seguridad, recomienda agregar uno (ej., REG-07: “El sistema debe sanitizar todos los campos de entrada”).
Test cases adicionales sugeridos:
- TC-311: Email de confirmación contiene el nombre correcto del usuario (REG-03)
- TC-312: El enlace de confirmación expira después de 24 horas (REG-03)
- TC-313: Google OAuth cancelado por el usuario (REG-05)
- TC-314: Google OAuth con cuenta sin email (REG-05)
- TC-315: Registrarse con contraseña que cumple todos los criterios (REG-02, test positivo)
- TC-316: Registrarse con caracteres especiales en el nombre (REG-01)
Puntos Clave
- Una RTM vincula requisitos con test cases, creando una cadena trazable desde la necesidad de negocio hasta la verificación
- La trazabilidad hacia adelante asegura que cada requisito se pruebe; la trazabilidad hacia atrás asegura que cada test esté justificado
- Las RTMs revelan brechas de cobertura, soportan análisis de impacto y permiten auditorías de cumplimiento
- Comienza simple con una hoja de cálculo y evoluciona a herramientas dedicadas conforme crece el proyecto
- Trata la RTM como un documento vivo — actualízala durante todo el ciclo de vida del proyecto