Sprint S4 — Ejecución guiada y evidencia

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

Demo al cierre: abro un ciclo de QA y ejecuto escenarios paso a paso (Pass/Fail/Blocked), dentro y fuera de ciclo, capturando y conservando evidencia. · Bloques funcionales: G (parcial), H.

HU-015 — Abrir un ciclo de QA

Sprint/Épica: S4 · Ejecución guiada y evidencia · Bloque: G · Deriva de: CU-012 · Cubre: RF-066, RF-067, RF-068, RF-069 · Reglas: RN-028, RN-029 · Estado: Borrador

Historia

Como QA, quiero abrir un ciclo de pruebas contra un ambiente concreto y un conjunto de escenarios aprobados, para delimitar una iteración cuyos resultados signifiquen algo comparable y reproducible.

Objetivo / valor. Un ciclo es la unidad que da sentido a un resultado. Sin él, un Pass no dice contra qué configuración se probó. Al abrirlo se congela un snapshot inmutable del ambiente: la condición para que, meses después, un fallo pueda atribuirse a la configuración exacta que estaba vigente.

Alcance

• Dentro: apertura del ciclo con nombre, objetivo y ambiente; selección del alcance

entre escenarios aprobados; advertencia por readiness incompleto; captura del snapshot inmutable; incorporación de los escenarios del alcance en Not run.

• Fuera: la ejecución de los escenarios (HU-016), el registro y preparación del

ambiente (HU-014), la aprobación del plan (HU-013) y el cierre del ciclo (HU-022).

Actores y permisos

Precondiciones

• El plan de pruebas está Aprobado (RN-033).
• Existe al menos un ambiente registrado en el proyecto.
• Existe al menos un escenario en estado Aprobado.

Comportamiento funcional

• Principal. El usuario abre un ciclo indicando nombre y objetivo, selecciona el

ambiente contra el que se ejecutará y elige los escenarios aprobados que componen el alcance. El sistema muestra el estado del checklist de readiness del ambiente. El usuario confirma la apertura; el sistema captura un snapshot inmutable de la configuración del ambiente y lo asocia al ciclo, que queda Abierto. Todos los escenarios del alcance quedan en Not run.

• Alternativo A1 — ciclo de regresión. El usuario compone el alcance con escenarios de

casos de uso ya validados en ciclos anteriores. El sistema no lo trata como caso especial: es un ciclo más, con su propio snapshot.

• Alternativo A2 — escenarios desactualizados en el alcance. El sistema advierte cuáles

están marcados como desactualizados y permite continuar; la advertencia se conserva (RN-037).

• Error E1 — plan no aprobado. El sistema impide abrir el ciclo e indica que el plan

requiere aprobación del Product Manager (RN-033, RN-034).

• Error E2 — checklist incompleto. El sistema advierte, no bloquea, y registra en el

ciclo el estado del checklist al momento de abrir, para que un fallo posterior pueda atribuirse a un ambiente mal preparado (RN-028).

Datos y campos (funcional, no esquema)

• Captura el usuario: nombre del ciclo, objetivo, ambiente seleccionado, conjunto de

escenarios del alcance.

• Deriva el sistema: snapshot inmutable de la configuración del ambiente, estado del

checklist de readiness al abrir, fecha de inicio, escenarios del alcance en Not run.

Reglas de negocio aplicables

• RN-028 — un checklist incompleto no impide abrir, pero la advertencia y el estado del

checklist quedan registrados en el ciclo.

• RN-029 — al abrir se captura un snapshot inmutable del ambiente; los cambios

posteriores al ambiente no alteran el snapshot del ciclo abierto.

• RN-033 / RN-034 — el plan debe estar Aprobado para abrir el ciclo; solo componen el

alcance escenarios en Aprobado.

Estados y transiciones. El ciclo sigue su máquina de estados: [*] → Abierto. Cada escenario del alcance entra en Not run en la máquina de ejecución.

Integraciones (documentado, el dev implementa)

• Vault de secretos — el snapshot congela referencias a secretos del ambiente,

nunca sus valores (RN-012, RN-026). El contrato fino se cierra con PA-008.

Eventos que emite. El catálogo canónico de eventos (RF-117) no define un evento para la apertura de ciclo; solo el cierre emite cycle.completed (HU-022). Ver Casos borde / notas.

Criterios de aceptación

• CA-190

> Dado un plan Aprobado, un ambiente registrado y escenarios en Aprobado > Cuando el QA abre un ciclo con nombre, objetivo, ambiente y un conjunto de escenarios aprobados > Entonces el ciclo queda Abierto, el sistema captura un snapshot inmutable del ambiente y todos los escenarios del alcance quedan en Not run.

• CA-191

> Dado un ciclo recién abierto sobre un ambiente > Cuando alguien modifica la configuración de ese ambiente después de la apertura > Entonces el snapshot asociado al ciclo no cambia y sigue reflejando la configuración vigente al abrir.

• CA-192

> Dado un plan que no está en estado Aprobado > Cuando el usuario intenta abrir un ciclo > Entonces el sistema lo impide e indica que el plan requiere aprobación del Product Manager.

• CA-193

> Dado un ambiente con checklist de readiness incompleto > Cuando el usuario confirma la apertura del ciclo > Entonces el sistema advierte, permite continuar y registra en el ciclo el estado del checklist al momento de abrir.

• CA-194

> Dado un alcance que incluye escenarios marcados como desactualizados > Cuando el usuario abre el ciclo > Entonces el sistema advierte cuáles están desactualizados, permite continuar y conserva la advertencia.

Dependencias y bloqueos

• PA-008 (vault de secretos) — condiciona la referencia a secretos incluida en el

snapshot; el comportamiento local no depende de ella.

• HU-013 (aprobar el plan) y HU-014 (registrar el ambiente) son precondición.
• HU-016 (ejecución guiada) consume los escenarios Not run del ciclo.

Casos borde / notas. El MVP no define un evento de dominio para la apertura del ciclo; si se necesitara notificar la apertura, se registra como hueco (ver PA de eventos) y no se inventa aquí. El snapshot es la pieza que hace reproducible cada ejecución del ciclo: toda ejecución dentro de él hereda ese mismo snapshot (RN-042).

HU-016 — Ejecutar un escenario de forma guiada

Sprint/Épica: S4 · Ejecución guiada y evidencia · Bloque: G · Deriva de: CU-013 · Cubre: RF-070, RF-071, RF-072, RF-073, RF-074, RF-075, RF-076, RF-079, RF-083–RF-088 · Reglas: RN-013, RN-038, RN-040, RN-042, RN-043, RN-046, RN-047 · Decisiones: DEC-031, DEC-053 · Estado: Borrador

Historia

Como Developer, quiero ejecutar un escenario paso a paso, con el resultado esperado a la vista y la evidencia adjunta en cada resultado, para validar con el mismo criterio que cualquier otra persona, sin conocimiento previo del proyecto, y dejar un registro inmutable de lo que probé.

Objetivo / valor. Es el caso central del producto: que una persona sin contexto valide con el mismo estándar que cualquier otra. La guía elimina la interpretación y la evidencia obligatoria elimina la afirmación sin respaldo. El resultado es un registro inmutable que sostiene la diferencia entre validado y dije que lo probé.

Alcance

• Dentro: apertura del escenario en el ciclo activo, confirmación de precondiciones,

ejecución guiada paso a paso, resultado por paso (Pass, Fail, No ejecutado), evidencia por paso y por ejecución, cálculo del resultado global propuesto, cierre de una ejecución detenida, y registro inmutable con contexto completo.

• Fuera: la ejecución fuera de ciclo (HU-017), la reejecución tras corrección (HU-018),

el registro del bug desde un Fail (HU-020), el registro del bloqueo desde un Blocked (HU-021) y el detalle del almacenamiento de evidencia (HU-019).

Actores y permisos

Precondiciones

• El escenario está Aprobado dentro de un plan aprobado (RN-034).
• Existe un ciclo Abierto que incluye el escenario en su alcance.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El usuario abre un escenario del ciclo activo. El sistema presenta las

precondiciones, el ambiente requerido, los datos de prueba y el rol necesario; el usuario confirma que las precondiciones se cumplen. El sistema presenta cada paso con su resultado esperado; el usuario ejecuta el paso en el sistema bajo prueba, registra el resultado observado (Pass o Fail), puede anotar observaciones y adjunta evidencia del paso. Al agotar los pasos, el sistema propone el resultado global según los resultados por paso y el criterio de aprobación; si algún paso quedó en Fail o No ejecutado, el resultado global no puede ser Pass (RN-043). El usuario confirma el resultado global y adjunta la evidencia final si corresponde. El sistema valida que exista al menos un elemento de evidencia y registra la ejecución como registro inmutable, con usuario, timestamp, ciclo, ambiente y snapshot heredado del ciclo (RN-042).

• Alternativo A1 — un paso falla y se continúa. El usuario marca el paso como Fail,

adjunta su evidencia y sigue con los pasos restantes. El resultado global no podrá ser Pass (RN-043). Desde el paso Fail puede invocar el registro de un bug (HU-020).

• Alternativo A2 — ejecución detenida. El usuario detiene la ejecución antes de agotar los

pasos. Debe cerrarla igual con resultado global Fail o Blocked; los pasos que no se corrieron quedan en No ejecutado. No existe la ejecución abandonada sin resultado (RN-084, DEC-053). Sigue rigiendo la evidencia obligatoria.

• Alternativo A3 — impedimento para probar. El usuario marca la ejecución como Blocked,

lo que exige asociar un bloqueo (HU-021, RN-039).

• Alternativo A4 — interrupción y reanudación. El usuario cierra la pestaña a mitad de la

ejecución. Al volver, el sistema restaura el progreso registrado hasta ese punto; nada se cierra ni se pierde por la interrupción.

• Error E1 — intento de registrar sin evidencia. El sistema rechaza el registro en

cualquier resultado, incluido Pass (RN-013, RN-046, DEC-031).

• Error E2 — fallo al almacenar la evidencia. El sistema informa el error y conserva el

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

• Error E3 — escenario no aprobado. El sistema impide la ejecución (RN-034).

Datos y campos (funcional, no esquema)

• Presenta el sistema: precondiciones, ambiente requerido, datos de prueba, rol

necesario, cada paso con su resultado esperado, criterio de aprobación.

• Captura el usuario: confirmación de precondiciones, resultado por paso (Pass, Fail,

No ejecutado), observaciones por paso y por escenario, evidencia por paso y final, resultado global confirmado.

• Deriva el sistema: resultado global propuesto, usuario ejecutor, timestamp, ciclo,

ambiente, snapshot heredado, marca de ejecución dentro de ciclo.

Reglas de negocio aplicables

• RN-013 / RN-046 — ningún resultado se registra sin al menos un elemento de evidencia,

incluido Pass.

• RN-038 / RN-062 — esta ejecución pertenece al ciclo y sí computa en cobertura y

avance (a diferencia de la fuera de ciclo, HU-017).

• RN-040 — la ejecución es inmutable una vez registrada; una corrección se refleja

reejecutando (HU-018), nunca editando.

• RN-042 — la ejecución hereda el snapshot de ambiente del ciclo.
• RN-043 — un paso en Fail o No ejecutado impide un resultado global Pass.
• RN-047 — cada elemento de evidencia registra automáticamente su metadata (usuario,

timestamp, ejecución, paso, escenario, ciclo, ambiente, tipo, tamaño, hash); no la edita el usuario.

• RN-084 — una ejecución detenida se cierra igual con Fail o Blocked, y los pasos no

corridos quedan No ejecutado.

Estados y transiciones. El escenario dentro del ciclo sigue la máquina de ejecución: Not run → Pass, Not run → Fail o Not run → Blocked. Blocked exige un bloqueo asociado (RN-039); el paso a Pass exige todos los pasos conformes (RN-043).

Integraciones (documentado, el dev implementa)

• S3 — los binarios de evidencia se almacenan en S3; la base guarda metadata y

referencias (RN-048). Si el almacenamiento falla, la ejecución no se cierra (Error E2). El detalle vive en HU-019.

Eventos que emite. test_case.failed cuando el resultado global es Fail; test_case.blocked cuando es Blocked. Un Pass no emite evento de fallo.

Criterios de aceptación

• CA-195

> Dado un escenario Aprobado incluido en un ciclo Abierto > Cuando el ejecutor lo abre > Entonces el sistema presenta precondiciones, ambiente requerido, datos de prueba y rol necesario, y exige confirmarlas antes de mostrar el primer paso.

• CA-196

> Dado un escenario en ejecución > Cuando el sistema presenta un paso > Entonces muestra su resultado esperado y permite registrar el resultado observado del paso de forma individual, con Pass, Fail o No ejecutado.

• CA-197

> Dado un paso ejecutado > Cuando el usuario intenta avanzar sin adjuntar evidencia de ese resultado > Entonces el sistema impide registrar el resultado hasta que exista al menos un elemento de evidencia.

• CA-198

> Dado un escenario con todos los pasos en Pass y evidencia en cada uno > Cuando el usuario confirma el resultado global con al menos un elemento de evidencia > Entonces el sistema propone Pass, registra la ejecución como registro inmutable con usuario, timestamp, ciclo, ambiente y snapshot, y no emite ningún evento de fallo.

• CA-199

> Dado un escenario con al menos un paso en Fail > Cuando el sistema calcula el resultado global propuesto > Entonces el resultado global no puede ser Pass.

• CA-200

> Dado un escenario con al menos un paso en No ejecutado > Cuando el sistema calcula el resultado global propuesto > Entonces el resultado global no puede ser Pass.

• CA-201

> Dado una ejecución que el usuario detiene antes de agotar sus pasos > Cuando la cierra > Entonces el sistema exige un resultado global Fail o Blocked, marca los pasos no corridos como No ejecutado y exige evidencia para cerrar.

• CA-202

> Dado una ejecución que resulta Fail > Cuando el sistema la registra > Entonces emite test_case.failed.

• CA-203

> Dado una ejecución que el usuario marca como Blocked > Cuando confirma el resultado > Entonces el sistema exige asociar un bloqueo antes de registrar y, al registrarla, emite test_case.blocked.

• CA-204

> Dado un intento de registrar cualquier resultado —incluido Pass— sin ningún elemento de evidencia > Cuando el usuario confirma > Entonces el sistema rechaza el registro e indica que la evidencia es obligatoria.

• CA-205

> Dado una ejecución ya registrada > Cuando un usuario intenta editarla > Entonces el sistema lo impide: la ejecución es inmutable y una corrección se refleja reejecutando.

• CA-206

> Dado una ejecución interrumpida a mitad de camino > Cuando el ejecutor vuelve a abrir el escenario > Entonces el sistema restaura el progreso registrado hasta ese punto sin cerrar ni perder la ejecución.

• CA-207

> Dado una ejecución dentro de un ciclo Abierto > Cuando se registra su resultado > Entonces la ejecución computa en las métricas de cobertura y avance de ese ciclo.

Dependencias y bloqueos

• HU-015 (abrir ciclo) aporta el ciclo, el ambiente y el snapshot heredado.
• HU-019 (evidencia) implementa el almacenamiento y la metadata que esta HU exige.
• HU-020 (bug desde un fallo) y HU-021 (bloqueo) parten de los resultados Fail y

Blocked producidos aquí.

Casos borde / notas. La ejecución guiada dentro de ciclo y la fuera de ciclo comparten el mismo flujo paso a paso; la diferencia está en el snapshot y en el cómputo de métricas, y esa diferencia vive en HU-017. Un resultado global Fail no obliga a abrir un bug: puede quedar abierto y transitar por reejecución con motivo (RN-078, HU-018).

HU-017 — Ejecutar un escenario fuera de ciclo

Sprint/Épica: S4 · Ejecución guiada y evidencia · Bloque: G · Deriva de: CU-013 (flujo A1) · Cubre: RF-070, RF-071 · Reglas: RN-038, RN-062, RN-080 · Decisiones: DEC-048, DEC-055 · Estado: Borrador

Historia

Como Developer, quiero ejecutar un escenario aprobado sin abrir un ciclo, eligiendo un ambiente compatible, para hacer una verificación puntual con trazabilidad y evidencia completas, sin que ese resultado altere las métricas del ciclo.

Objetivo / valor. No toda verificación merece un ciclo. La ejecución fuera de ciclo permite comprobar algo puntual —una corrección local, una duda— con el mismo rigor de evidencia, pero mantenida aparte de las métricas para no distorsionar la lectura del avance.

Alcance

• Dentro: ejecución de un escenario Aprobado sin ciclo abierto, elección explícita de

un ambiente compatible, captura de un snapshot propio, registro con trazabilidad y evidencia completas, y separación de las métricas.

• Fuera: la ejecución dentro de ciclo (HU-016), de la que hereda el flujo guiado paso a

paso; la apertura de ciclos (HU-015).

Actores y permisos

Precondiciones

• El escenario está en estado Aprobado. No se exige plan aprobado: la ejecución fuera

de ciclo depende del estado del escenario, no del plan (RN-034, DEC-055).

• Existe al menos un ambiente del proyecto cuyo tipo coincide con el ambiente requerido por

el escenario (RN-080).

Comportamiento funcional

• Principal. El usuario ejecuta un escenario Aprobado sin un ciclo abierto. El sistema

exige elegir explícitamente el ambiente entre los del proyecto cuyo tipo coincide con el ambiente requerido por el escenario. Captura un snapshot propio del ambiente elegido en ese instante y marca la ejecución como fuera de ciclo. El resto del flujo —paso a paso, resultado por paso, evidencia obligatoria, resultado global, registro inmutable— es el de HU-016. La ejecución se registra con trazabilidad y evidencia completas, pero no computa en cobertura ni avance.

• Error E1 — sin ambiente compatible. Si no existe ningún ambiente del proyecto cuyo tipo

coincida con el requerido por el escenario, el sistema impide la ejecución e indica qué tipo de ambiente falta registrar (RN-080).

Datos y campos (funcional, no esquema)

• Captura el usuario: ambiente elegido entre los compatibles; luego, el mismo flujo de

resultado por paso y evidencia de HU-016.

• Deriva el sistema: snapshot propio del ambiente elegido en el momento de ejecutar,

marca de fuera de ciclo, exclusión de las métricas de cobertura y avance.

Reglas de negocio aplicables

• RN-038 / RN-062 — la ejecución fuera de ciclo se registra con trazabilidad y evidencia

completas, pero no computa en las métricas de cobertura ni de avance.

• RN-080 — se ejecuta contra un ambiente elegido explícitamente entre los del proyecto

cuyo tipo coincide con el requerido por el escenario; sin ambiente compatible no hay ejecución fuera de ciclo. Dos ejecuciones fuera de ciclo del mismo escenario solo son comparables si declaran el mismo ambiente.

• RN-042 — al no pertenecer a un ciclo, la ejecución captura su propio snapshot en el

momento de ejecutarse.

Estados y transiciones. El resultado de la ejecución sigue la máquina de ejecución, pero el estado no forma parte del avance de ningún ciclo. Sigue rigiendo la evidencia obligatoria y, si el resultado es Pass, la restricción de RN-043.

Integraciones (documentado, el dev implementa)

• S3 — almacenamiento de evidencia idéntico al de HU-016 (RN-048); el detalle en HU-019.
• Vault de secretos — el snapshot propio congela referencias a secretos, nunca valores.

Eventos que emite. test_case.failed o test_case.blocked según el resultado, igual que HU-016. La separación de métricas no suprime la emisión del evento de dominio.

Criterios de aceptación

• CA-208

> Dado un escenario Aprobado y ningún ciclo abierto > Cuando el usuario inicia una ejecución fuera de ciclo > Entonces el sistema exige elegir explícitamente un ambiente entre los del proyecto cuyo tipo coincide con el ambiente requerido por el escenario.

• CA-209

> Dado un escenario cuyo ambiente requerido no coincide con el tipo de ningún ambiente registrado del proyecto > Cuando el usuario intenta ejecutarlo fuera de ciclo > Entonces el sistema lo impide e indica qué tipo de ambiente falta registrar.

• CA-210

> Dado un ambiente compatible elegido > Cuando el usuario inicia la ejecución fuera de ciclo > Entonces el sistema captura un snapshot propio del ambiente elegido en ese instante y marca la ejecución como fuera de ciclo.

• CA-211

> Dado una ejecución fuera de ciclo con resultado registrado y evidencia completa > Cuando el sistema actualiza las métricas > Entonces la ejecución no computa en cobertura ni en avance, y el sistema la distingue visualmente de las ejecuciones de ciclo.

• CA-212

> Dado un escenario Aprobado cuyo plan volvió a Pendiente de aprobación por la edición de otro escenario > Cuando el usuario ejecuta ese escenario fuera de ciclo > Entonces el sistema lo permite, porque la ejecución fuera de ciclo depende del estado del escenario y no del plan.

Dependencias y bloqueos

• HU-016 (ejecución guiada) aporta el flujo paso a paso que esta HU reutiliza.
• HU-014 (ambientes) provee los ambientes cuyo tipo debe coincidir con el requerido.

Casos borde / notas. La única diferencia funcional con HU-016 es el origen del snapshot —propio, no heredado de un ciclo— y la exclusión de las métricas. Todo lo demás —guía, evidencia obligatoria, inmutabilidad— es idéntico. Comparar dos ejecuciones fuera de ciclo solo tiene sentido si ambas declaran el mismo ambiente (RN-080).

HU-019 — Capturar y conservar evidencia

Sprint/Épica: S4 · Ejecución guiada y evidencia · Bloque: H · 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.