Trazar requisito, prueba y evidencia

Una matriz de trazabilidad tiene una fila por requisito: su identificador con versión, su nivel, la historia y el criterio que lo bajan a la aplicación, la prueba que lo comprueba, el tipo de prueba, el estado y la evidencia (el identificador de una ejecución, de una revisión o de un documento). La evidencia no es la palabra «cumple»: es algo que otra persona puede abrir y leer.

La matriz sirve en dos sentidos. Hacia adelante: dado un requisito, ¿qué prueba lo comprueba y cuándo pasó por última vez? Hacia atrás: si una prueba falla o un componente cambia, ¿qué requisitos quedan en duda?

Lo primero que se comprueba es que cada evidencia exista. Una fila puede decir «cumple» y apuntar a una ejecución que nunca ocurrió, o que se borró, o que alguien escribió de memoria. Una auditoría que encuentra eso deja de confiar en toda la matriz.

Abre el laboratorio y cruza la columna evidencia de matriz-trazabilidad.csv con registro-ejecuciones.txt.

Una evidencia vale para el código que se probó. Si el componente cambió después, la prueba vieja no dice nada sobre el código de hoy: hay que volver a ejecutarla. Por eso la matriz lleva el componente de cada requisito, y cada cambio desplegado tiene que disparar una revisión de las filas de ese componente.

Cruza las fechas de registro-ejecuciones.txt con cambios-componentes.txt.

Antes de aprobar una salida a producción, la pregunta más sencilla es también la más importante: ¿queda algún requisito del nivel más bajo sin ninguna prueba asociada? Los requisitos de documentación cuentan como probados si tienen su revisión de documento; una fila sin prueba no se puede aprobar, sea del tipo que sea.

Que la evidencia exista y sea reciente no basta: tiene que comprobar lo que el requisito pide. La fila del requisito que exige que la extensión coincida con el contenido apunta al criterio CA-09, el que solo sube un JPG válido. La ejecución existe, pasó en verde y es posterior a los cambios, y aun así no demuestra nada sobre archivos falsos.