Épica G — Ciclos y ejecución

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

Cubre el corazón operativo del producto: abrir la iteración de pruebas sobre un ambiente congelado, ejecutar un escenario paso a paso con evidencia obligatoria, la verificación puntual fuera de ciclo que no contamina las métricas, y la reejecución tras una corrección sin borrar el registro de que antes falló. Reglas de negocio del bloque: RN-038 a RN-045, más RN-013, RN-046, RN-047, RN-055, RN-062, RN-078, RN-080 y RN-084.

HU-015 — Abrir un ciclo de QA

Épica: G · Ciclos y ejecución · 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

Épica: G · Ciclos y ejecución · 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

Épica: G · Ciclos y ejecución · 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-018 — Reejecutar tras una corrección

Épica: G · Ciclos y ejecución · Deriva de: CU-016 · Cubre: RF-079, RF-080, RF-098, RF-099 · Reglas: RN-040, RN-041, RN-044, RN-055 · Estado: Borrador

Historia

Como Developer, quiero reejecutar un escenario que falló, una vez corregido el defecto, creando un registro nuevo sin borrar el anterior, para confirmar con evidencia que la corrección funciona sin perder la constancia de que antes falló.

Objetivo / valor. La corrección no borra la historia. Reejecutar crea un registro nuevo; el fallo original queda intacto. Passed after fix distingue una aprobación tras corregir de una que pasó a la primera: no son la misma señal de calidad.

Alcance

• Dentro: disparo del retest cuando un bug pasa a Listo para retest, paso de las

ejecuciones fallidas a Retest required, reejecución que crea un registro nuevo, y desenlace según el resultado (Passed after fix, Fail con reapertura del bug, o Blocked), incluida la reapertura tardía de un bug ya cerrado.

• Fuera: la ejecución guiada en sí (HU-016, que esta HU invoca), el registro del bug

(HU-020) y la resolución del bloqueo (HU-021, que también libera ejecuciones a Retest required).

Actores y permisos

Precondiciones

• Existe un bug en estado Listo para retest, o un bloqueo recién resuelto (HU-021).
• Existe al menos una ejecución fallida asociada al bug.

Comportamiento funcional

• Principal. El desarrollador marca el bug como Listo para retest. El sistema emite

bug.ready_for_retest y pasa a Retest required las ejecuciones fallidas que lo originaron. El ejecutor abre el escenario y lo ejecuta nuevamente siguiendo el flujo guiado (HU-016). El sistema crea un registro de ejecución nuevo; el anterior se conserva intacto e inmutable. Si el resultado es conforme, el escenario queda en Passed after fix y el bug puede pasar a Resuelto.

• Alternativo A1 — el retest vuelve a fallar. El escenario queda en Fail y el bug pasa a

Reabierto. El sistema emite bug.reopened.

• Alternativo A2 — aparece un impedimento nuevo. El escenario pasa a Blocked con su

bloqueo asociado (HU-021, RN-039).

• Alternativo A3 — reapertura tardía. Un bug ya Cerrado reaparece. La reapertura exige

motivo y evidencia nueva; sin ambos, el sistema la impide (RN-055). El sistema emite bug.reopened.

• Error E1 — intento de editar la ejecución fallida original. El sistema lo rechaza: las

ejecuciones son inmutables. La corrección se refleja reejecutando, con ambos registros visibles (RN-040, RN-044).

Datos y campos (funcional, no esquema)

• Captura el usuario: marca de Listo para retest; en la reapertura tardía, motivo y

evidencia nueva; luego el flujo de resultado por paso y evidencia de HU-016.

• Deriva el sistema: transición de las ejecuciones fallidas a Retest required, registro

de ejecución nuevo enlazado al escenario, estado resultante del escenario (Passed after fix, Fail o Blocked), transición del bug (Resuelto o Reabierto).

Reglas de negocio aplicables

• RN-040 / RN-044 — la reejecución crea un registro nuevo; nunca sobrescribe ni edita el

anterior. El error de un registro se corrige reejecutando, dejando ambos visibles.

• RN-041 — cuando el bug pasa a Listo para retest, las ejecuciones fallidas que lo

originaron pasan a Retest required.

• RN-055 — la reapertura de un bug exige motivo y evidencia nueva.

Estados y transiciones. El escenario sigue la máquina de ejecución: Fail → Retest required (por bug listo para retest, RN-041), y desde Retest required a Passed after fix (conforme), Fail (no conforme) o Blocked (nuevo impedimento). El bug sigue su máquina: Listo para retest → Resuelto o → Reabierto, y Cerrado → Reabierto con motivo y evidencia (RN-055).

Integraciones (documentado, el dev implementa)

• S3 — evidencia de la reejecución y de la reapertura, igual que HU-016/HU-019.
• Argos Operaciones — la transición del bug se refleja en su ticket espejo enlazado; el

contrato fino se cierra con PA-006 (ver HU-020). El comportamiento local no depende de él.

Eventos que emite. bug.ready_for_retest al marcar el bug listo para retest; bug.reopened cuando el retest vuelve a fallar o cuando un bug cerrado se reabre.

Criterios de aceptación

• CA-213

> Dado un bug con ejecuciones fallidas asociadas > Cuando el desarrollador lo marca como Listo para retest > Entonces el sistema emite bug.ready_for_retest y pasa a Retest required las ejecuciones fallidas que lo originaron.

• CA-214

> Dado un escenario en Retest required > Cuando el ejecutor lo reejecuta con evidencia > Entonces el sistema crea un registro de ejecución nuevo y conserva intacto e inmutable el registro de la ejecución fallida anterior.

• CA-215

> Dado una reejecución con resultado conforme > Cuando el sistema la registra > Entonces el escenario queda en Passed after fix y el bug puede pasar a Resuelto.

• CA-216

> Dado una reejecución que vuelve a fallar > Cuando el sistema la registra > Entonces el escenario queda en Fail, el bug pasa a Reabierto y se emite bug.reopened.

• CA-217

> Dado un bug en estado Cerrado que reaparece > Cuando el usuario intenta reabrirlo sin aportar motivo y evidencia nueva > Entonces el sistema impide la reapertura hasta que ambos se aporten.

• CA-218

> Dado un bug Cerrado que reaparece > Cuando el usuario lo reabre con motivo y evidencia nueva > Entonces el sistema lo reabre y emite bug.reopened.

• CA-219

> Dado la ejecución fallida original de un escenario > Cuando un usuario intenta editarla para reflejar la corrección > Entonces el sistema lo rechaza: la ejecución es inmutable y la corrección se refleja reejecutando, con ambos registros visibles.

Dependencias y bloqueos

• HU-016 (ejecución guiada) provee el flujo de la reejecución.
• HU-020 (bug desde un fallo) aporta el bug cuyo cambio de estado dispara el retest.
• HU-021 (bloqueo) libera ejecuciones a Retest required por la vía del bloqueo resuelto

(RN-058), alternativa al bug listo para retest.

Casos borde / notas. Un Fail sin bug asociado puede pasar a Retest required por decisión de quien ejecuta, con un motivo escrito que queda en auditoría (RN-078, RF-079); esa vía es distinta de la de RN-041, que aplica a un Fail con bug. La reejecución puede ocurrir dentro del mismo ciclo (RF-079) o tras reabrir uno cerrado (HU-022); en ambos casos cada registro se conserva por separado.