En un proyecto de software, los requisitos indican qué debe construirse, los casos de prueba indican cómo se verificará y los defectos muestran qué problemas se encontraron. La trazabilidad conecta estos elementos.
Sin trazabilidad, puede ser difícil responder preguntas simples: ¿qué pruebas cubren este requisito?, ¿qué defectos afectan esta funcionalidad?, ¿qué casos debemos repetir si cambia una regla?, ¿qué requisitos quedaron sin probar?
En este tema veremos qué es la trazabilidad, para qué sirve y cómo aplicarla de forma práctica.
La trazabilidad es la capacidad de relacionar elementos del proyecto entre sí. En testing, normalmente buscamos conectar requisitos, criterios de aceptación, casos de prueba, ejecuciones, defectos y versiones.
Ejemplo simple:
Otro ejemplo:
Estas relaciones permiten seguir el recorrido desde lo que se pidió hasta lo que se probó y lo que falló.
La trazabilidad sirve para:
No se trata de crear burocracia. Se trata de poder responder preguntas importantes con menos incertidumbre.
Según el proyecto, podemos relacionar:
No siempre hace falta relacionarlo todo. El nivel de trazabilidad debe ser proporcional al riesgo y tamaño del proyecto.
Podemos pensar la trazabilidad en dos direcciones:
| Dirección | Pregunta | Ejemplo |
|---|---|---|
| Hacia adelante | Desde un requisito, ¿qué pruebas y defectos lo cubren? | R-LOGIN-01 está cubierto por CP-LOGIN-001 y CP-LOGIN-002. |
| Hacia atrás | Desde una prueba o defecto, ¿qué requisito lo justifica? | DEF-231 afecta el requisito R-PAGO-02. |
Ambas direcciones son útiles. Una ayuda a medir cobertura; la otra ayuda a entender propósito e impacto.
Una forma común de representar trazabilidad es una matriz de trazabilidad. Puede ser una tabla simple donde se relacionan requisitos con casos de prueba y defectos.
| Requisito | Descripción | Casos de prueba | Defectos | Estado |
|---|---|---|---|---|
| R-LOGIN-01 | Inicio de sesión con credenciales válidas. | CP-LOGIN-001 | - | Cubierto y aprobado. |
| R-LOGIN-02 | Rechazo de contraseña incorrecta. | CP-LOGIN-002 | DEF-238 | Cubierto con defecto abierto. |
| R-PAGO-01 | Pago aprobado. | CP-PAGO-001, CP-PAGO-002 | - | Cubierto parcialmente. |
| R-REPORTE-03 | Exportar reporte mensual. | - | - | Sin cobertura. |
Esta tabla permite ver rápidamente qué requisitos están cubiertos, fallidos o sin pruebas.
La trazabilidad ayuda a medir cobertura de requisitos. Por ejemplo:
Podemos decir que hay 80% de requisitos con cobertura, pero debemos analizar calidad de esa cobertura. Un requisito puede tener un caso asociado y aun así estar probado de forma insuficiente.
Cuando cambia un requisito, la trazabilidad ayuda a identificar qué pruebas deben revisarse o repetirse.
Ejemplo:
Con trazabilidad podemos buscar:
Sin trazabilidad, el equipo puede olvidar pruebas importantes después del cambio.
Relacionar defectos con requisitos o casos de prueba ayuda a entender impacto.
Ejemplo:
| Defecto | Descripción | Requisito afectado | Caso relacionado |
|---|---|---|---|
| DEF-238 | Error 500 con contraseña incorrecta. | R-LOGIN-02 | CP-LOGIN-002 |
| DEF-245 | El total no incluye descuento premium. | R-COMPRA-05 | CP-COMPRA-014 |
Esto permite responder qué funcionalidad queda comprometida por cada defecto.
La trazabilidad ayuda a seleccionar pruebas de regresión. Si sabemos qué requisitos y casos están relacionados con un cambio, podemos elegir una regresión más inteligente.
Ejemplo: si se cambia la regla de promociones, debemos buscar:
Así evitamos elegir regresión solo por intuición.
Supongamos estos requisitos:
| Requisito | Criterio | Caso | Resultado última ejecución | Defecto |
|---|---|---|---|---|
| R-REC-01 | Enviar enlace si el correo existe. | CP-REC-001 | Aprobado | - |
| R-REC-02 | Rechazar enlace vencido. | CP-REC-002 | Aprobado | - |
| R-REC-03 | Rechazar reutilización de enlace. | CP-REC-003 | Fallido | DEF-310 |
Con esta tabla sabemos que la recuperación de contraseña está parcialmente cubierta, pero tiene un defecto abierto en reutilización de enlaces.
En proyectos ágiles, la trazabilidad puede ser más liviana, pero sigue siendo útil. Puede relacionar historias de usuario, criterios de aceptación, pruebas y defectos.
Ejemplo:
No siempre hace falta una matriz formal. A veces basta con usar enlaces en la herramienta de gestión, nombres consistentes y casos vinculados a historias.
En proyectos regulados o de alto riesgo, la trazabilidad suele ser más formal. Puede requerirse demostrar que cada requisito fue probado y que cada defecto fue gestionado.
Ejemplos de contextos donde puede ser más estricta:
En estos casos, la trazabilidad ayuda a generar evidencia verificable del proceso de calidad.
La trazabilidad puede gestionarse con distintas herramientas:
La herramienta no es lo más importante. Lo importante es que las relaciones sean claras, mantenibles y consultables.
La trazabilidad mejora cuando usamos identificadores consistentes.
Ejemplos:
Los identificadores permiten referenciar elementos sin depender de títulos largos o ambiguos.
La trazabilidad debe mantenerse. Si los requisitos cambian y las relaciones no se actualizan, la información pierde confianza.
Situaciones que requieren actualización:
La trazabilidad desactualizada puede ser peor que no tener trazabilidad, porque genera falsa confianza.
Al trabajar con trazabilidad, algunos errores frecuentes son:
La trazabilidad debe ser útil y mantenible, no una carga artificial.
Para aplicar trazabilidad de forma efectiva conviene:
La trazabilidad permite conectar lo que se pidió, lo que se probó y lo que falló. Ayuda a medir cobertura, analizar impacto, seleccionar regresión y comunicar riesgos con mayor claridad.
Una trazabilidad útil no necesita ser compleja, pero sí debe mantenerse. Su valor aparece cuando permite responder preguntas importantes de forma rápida y confiable.
En el próximo tema estudiaremos riesgos comunes al probar software, para identificar problemas frecuentes que pueden afectar el proceso de testing y la calidad de los resultados.