Épica H — Evidencia

Estado: Borrador · Última actualización: 2026-08-24 · Índice: README

Cubre la evidencia como respaldo inmutable y auditable de toda validación: su captura, su metadata automática, su almacenamiento y su retención. Es transversal a la ejecución, los bugs y los reportes: sin evidencia no hay resultado. Reglas de negocio del bloque: RN-010 y RN-046 a RN-050.

HU-019 — Capturar y conservar evidencia

Épica: H · Evidencia · Deriva de: Transversal · Cubre: RF-089, RF-090, RF-091 · Reglas: RN-010, RN-046, RN-047, RN-048, RN-049, RN-050 · Decisiones: DEC-020, DEC-061 · Estado: Borrador

Historia

Como ejecutor de pruebas, quiero que la evidencia que adjunto quede almacenada de forma inmutable, con su metadata y bajo una política de retención, para que cualquier resultado sea auditable y ningún hallazgo se sostenga sobre una afirmación sin respaldo.

Objetivo / valor. La evidencia es lo que separa "validado" de "dije que lo probé": una vez registrada no se altera ni se borra, se sirve solo bajo acceso controlado y sobrevive el tiempo que la política de retención exige.

Alcance

• Dentro: adjuntar screenshots, logs y archivos a un paso o a una ejecución; registro de

metadata automática; almacenamiento del binario en S3 con solo metadata y referencias en base de datos; acceso por URL firmada; auditoría de toda visualización y descarga; inmutabilidad; aplicación de la política de retención y aviso previo a la expiración.

• Fuera: la grabación de pantalla (excluida del MVP por DEC-006); la ejecución en sí

(HU-016) y el registro del bug (HU-020), que consumen esta evidencia pero no la definen; el contrato fino del almacenamiento (documentado, no diseñado).

Actores y permisos

Precondiciones

• Existe un paso o una ejecución en curso al que adjuntar la evidencia.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El ejecutor adjunta uno o más elementos —screenshot, log o archivo— a un paso

o a la ejecución completa. El sistema valida tipo y tamaño; sube el binario a S3 y guarda en base de datos solo su metadata y referencia; registra automáticamente la metadata no editable (usuario, timestamp, ejecución, paso, escenario, ciclo, ambiente, tipo, tamaño y hash del contenido). La evidencia queda asociada de forma permanente y no eliminable.

• Alternativo A1 — servir evidencia. Al visualizar o descargar un elemento, el sistema

entrega una URL firmada de vigencia limitada y registra el acceso en auditoría (usuario, timestamp, elemento). No existe acceso público ni enlace permanente.

• Alternativo A2 — consulta de expiración. El sistema permite consultar qué evidencia está

por vencer según la política de retención (RF-091). En el MVP es una vista informativa; la retención extendida manual es Fase 2 (DEC-061).

• Error E1 — tipo o tamaño no permitido. El sistema rechaza el elemento con un mensaje claro

y no lo almacena.

• Error E2 — fallo al subir a S3. El sistema informa el error y conserva el progreso de la

ejecución; el resultado no puede cerrarse hasta que la evidencia se almacene: sin storage no hay registro válido.

• Error E3 — intento de eliminación. El sistema lo rechaza: la evidencia solo desaparece por

vencimiento de la política de retención (RN-010).

Datos y campos (funcional, no esquema)

• Aporta el usuario: el archivo en sí (screenshot, log o adjunto) y su asociación a un paso

o a la ejecución.

• Registra el sistema, no editable: usuario, timestamp, ejecución, paso, escenario, ciclo,

ambiente, tipo, tamaño y hash del contenido.

• Deriva el sistema: referencia al objeto en S3, estado de retención y fecha estimada de

expiración.

Reglas de negocio aplicables

• RN-046 — todo resultado de ejecución exige al menos un elemento de evidencia, incluido

Pass. Es la regla que enlaza esta HU con la ejecución (HU-016) y el bug (HU-020): sin evidencia no hay resultado ni bug.

• RN-047 — la metadata se registra automáticamente y el usuario no la edita.
• RN-048 — el binario vive en S3; la base de datos guarda metadata y referencias, nunca el

binario.

• RN-049 — acceso siempre por URL firmada de vigencia limitada; sin acceso público ni

enlace permanente.

• RN-050 — toda visualización y descarga queda auditada.
• RN-010 — nadie elimina evidencia; solo expira por política de retención.

Estados y transiciones. La evidencia no tiene máquina de estados propia: nace, permanece inmutable y solo desaparece por vencimiento de la retención (DEC-020). La política es diferenciada por resultado: Pass 90 días, Fail/Blocked 12 meses (DEC-061).

Integraciones (documentado, el dev implementa)

• S3 (Amazon S3) — almacena los binarios de evidencia; la base de datos guarda solo

metadata y referencias. El dev implementa la subida, el versionado inmutable y la generación de URLs firmadas; aquí se documenta el comportamiento, no el contrato.

Eventos que emite. Ninguno propio. La evidencia es condición de los resultados y bugs que sí emiten eventos (test_case.failed, bug.created); su captura no dispara un evento de dominio por sí misma.

Criterios de aceptación

• CA-250

> Dado un paso de ejecución en curso > Cuando el ejecutor adjunta un screenshot, un log o un archivo de tipo y tamaño permitidos > Entonces el sistema lo almacena en S3, guarda en base de datos solo su metadata y referencia, y registra automáticamente usuario, timestamp, ejecución, paso, escenario, ciclo, ambiente, tipo, tamaño y hash sin permitir editarlos.

• CA-251

> Dado un intento de registrar el resultado de una ejecución sin ningún elemento de evidencia > Cuando el usuario confirma el resultado, incluido Pass > Entonces el sistema lo rechaza e indica que todo resultado exige al menos un elemento de evidencia.

• CA-252

> Dado un elemento de evidencia ya almacenado > Cuando cualquier usuario intenta eliminarlo > Entonces el sistema lo impide, porque la evidencia solo desaparece por vencimiento de la política de retención.

• CA-253

> Dado un usuario con permiso que visualiza o descarga un elemento de evidencia > Cuando el sistema entrega el archivo > Entonces lo sirve mediante una URL firmada de vigencia limitada, sin enlace público ni permanente, y registra el acceso en auditoría con usuario, timestamp y elemento.

• CA-254

> Dado un archivo cuyo tipo o tamaño excede los límites permitidos > Cuando el usuario intenta adjuntarlo > Entonces el sistema lo rechaza con un mensaje claro y no lo almacena.

• CA-255

> Dado un fallo al subir la evidencia a S3 > Cuando el usuario intenta cerrar la ejecución > Entonces el sistema informa el error, conserva el progreso y no permite cerrar el resultado hasta que la evidencia quede almacenada.

• CA-256

> Dado un conjunto de evidencia sujeto a la política de retención > Cuando el usuario consulta qué está por vencer > Entonces el sistema muestra los elementos próximos a expirar según el resultado de la ejecución asociada (Pass 90 días, Fail/Blocked 12 meses); en el MVP la vista es informativa, sin acción de retención extendida.

Dependencias y bloqueos

• PA-018 → resuelta (DEC-061). Plazos: Pass 90 días, Fail/Blocked 12 meses. La

retención extendida manual y la política de entregas formales quedan para Fase 2.

• HU-016 (ejecución guiada) y HU-020 (registro de bug) consumen esta evidencia y

dependen de RN-046 para poder cerrarse.

Casos borde / notas. DEC-020 deja definidas filas de video y trace que no aplican al MVP (DEC-006): se conservan porque condicionan el diseño del storage, pero en Fase 1 solo se capturan screenshots, logs y adjuntos. La metadata incluye el hash del contenido, que permite verificar la integridad del binario a lo largo de su retención.