Épica I — Bugs y bloqueos

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

Cubre el registro de defectos y su ticket espejo en Argos Operaciones, y el bloqueo como entidad propia con ciclo de vida. Reglas de negocio del bloque: RN-051 a RN-058, más RN-039 y RN-083.

HU-020 — Registrar un bug desde un fallo

Épica: I · Bugs y bloqueos · Deriva de: CU-014 · Cubre: RF-077, RF-092–RF-100 · Reglas: RN-051, RN-052, RN-053, RN-054, RN-056, RN-083 · Decisiones: DEC-033, DEC-052 · Estado: Borrador

Historia

Como Developer, quiero registrar un bug desde un paso fallido de una ejecución, para dejar un defecto reproducible y trazado hasta el requerimiento que lo originó, y ponerlo en el flujo de trabajo del equipo.

Objetivo / valor. Que ningún hallazgo se pierda ni quede sin contexto: el bug nace con toda la cadena de trazabilidad ya adjunta y con su ticket espejo en Argos Operaciones.

Alcance

• Dentro: creación desde un paso Fail, precarga de contexto inmutable, captura de los

datos del defecto, creación del ticket espejo, asignación y emisión del evento.

• Fuera: resolución y reejecución (HU-018), edición de la ejecución origen (es

inmutable), y el diseño del mapeo de campos bug→ticket (documentado, no diseñado).

Actores y permisos

Precondiciones

• Existe una ejecución con al menos un paso en Fail (para el flujo principal).
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. Desde el paso fallido, el sistema precarga el contexto no editable

(escenario, caso de uso y versión, paso, ciclo, ambiente, snapshot, referencia de código bajo prueba, ejecutor, timestamp, evidencia adjunta); el usuario completa los datos del defecto; el bug se guarda en Nuevo con sincronización Pendiente; el sistema crea el ticket espejo en Argos Operaciones, enlaza ambos de forma permanente y pasa la sincronización a Sincronizado; emite bug.created.

• Alternativo A1 — bug independiente. Sin partir de una ejecución; el usuario aporta

manualmente el contexto no heredable; sigue rigiendo la evidencia obligatoria.

• Alternativo A2 — asignación. A un miembro PM/QA/Developer; el bug pasa a Asignado;

emite bug.assigned y notifica.

• Error E1 — Argos Operaciones no responde. El bug queda local con sincronización

Pendiente y reintento automático acotado; el ejecutor no se bloquea ni pierde el hallazgo.

• Error E2 — reintentos agotados. La sincronización pasa a Error, visible, con opción de

reintento manual.

• Error E3 — sin evidencia. El sistema rechaza el registro.

Datos y campos (funcional, no esquema)

• Precargado inmutable: escenario, CU + versión, paso, ciclo, ambiente, snapshot,

referencia de código, ejecutor, timestamp, evidencia previa.

• Captura el usuario: título, descripción, severidad, pasos para reproducir, resultado

esperado, resultado obtenido, evidencia adicional (opcional).

Reglas de negocio aplicables

• RN-052 — sin evidencia no se registra el bug (incluido el independiente).
• RN-053 / RN-054 — ticket espejo automático y enlace permanente; con Argos Operaciones

caído, sincronización diferida con reintento.

• RN-051 / RN-056 — el bug hereda la cadena de trazabilidad hasta el requerimiento.
• RN-083 — un Client nunca es destinatario de asignación.

Estados y transiciones. Sigue la máquina de estados del bug: Nuevo → Asignado → …. La asignación es condición para salir de Nuevo (DEC-052).

Integraciones (documentado, el dev implementa)

• Argos Operaciones — crea el ticket espejo y mantiene el enlace permanente. El contrato

fino (endpoint, mapeo de campos) se cierra con PA-006 y PA-016; el comportamiento local no depende de ellas.

Eventos que emite. bug.created; bug.assigned al asignar.

Criterios de aceptación

• CA-270

> Dado un paso de ejecución en estado Fail > Cuando el Developer crea un bug desde ese paso y aporta título, severidad, pasos, esperado y obtenido con al menos un elemento de evidencia > Entonces el bug queda en Nuevo con sincronización Pendiente, con el contexto de la ejecución precargado y no editable.

• CA-271

> Dado un bug recién guardado y Argos Operaciones disponible > Cuando el sistema crea el ticket espejo > Entonces ambos quedan enlazados de forma permanente, la sincronización pasa a Sincronizado y se emite bug.created.

• CA-272

> Dado un intento de registrar un bug sin ningún elemento de evidencia > Cuando el usuario confirma el registro > Entonces el sistema lo rechaza e indica que la evidencia es obligatoria.

• CA-273

> Dado un bug guardado y Argos Operaciones sin responder > Cuando se agotan los reintentos automáticos > Entonces la sincronización queda en Error, visible, con opción de reintento manual, sin que el hallazgo se pierda.

• CA-274

> Dado un bug en Nuevo > Cuando se intenta asignarlo a un usuario con rol Client > Entonces el sistema lo impide.

Dependencias y bloqueos

• PA-006 (API de Argos Operaciones) y PA-016 (mapeo bug→ticket) — condicionan el

contrato del ticket espejo; el comportamiento local no depende de ellas.

• HU-018 (reejecutar tras corrección) consume el estado del bug.

HU-021 — Registrar y resolver un bloqueo

Épica: I · Bugs y bloqueos · Deriva de: CU-015 · Cubre: RF-078, RF-101–RF-105, RF-140 · Reglas: RN-039, RN-057, RN-058 · Decisiones: DEC-032, DEC-045 · Estado: Borrador

Historia

Como QA, quiero registrar un impedimento como un bloqueo con dueño y ciclo de vida propio, para distinguir lo que impide probar de lo que está defectuoso, y que ninguna de las dos cosas contamine la lectura de la otra.

Objetivo / valor. El bloqueo no se diluye en un comentario: es una entidad con tipo, responsable e impacto, y al resolverse libera automáticamente lo que dependía de él.

Alcance

• Dentro: creación del bloqueo al marcar una ejecución Blocked, su gestión y

resolución, y la liberación de las ejecuciones afectadas.

• Fuera: la ejecución en sí (HU-016) y el registro de bugs (HU-020); un bloqueo no es un

defecto.

Actores y permisos

Precondiciones

• Existe un impedimento que impide ejecutar uno o más escenarios.

Comportamiento funcional

• Principal. Al marcar una ejecución como Blocked, el sistema exige asociar un bloqueo;

el usuario crea uno nuevo o selecciona uno existente. Al crearlo indica tipo —Ambiente, Datos, Acceso, Dependencia externa, Definición pendiente—, descripción, responsable e impacto. El bloqueo queda Abierto y vinculado a la ejecución; se emiten blocker.created y test_case.blocked. Cuando alguien se hace cargo pasa a En gestión; al desaparecer el impedimento se marca Resuelto y el sistema pasa a Retest required todas las ejecuciones que dependían de él, emitiendo blocker.resolved.

• Alternativo A1 — alcance múltiple. Un mismo bloqueo se asocia a varias ejecuciones; al

resolverse, todas se liberan a la vez.

• Alternativo A2 — bloqueo descartado. Si no era un bloqueo real, las ejecuciones vuelven a

Not run (no a Retest required); el sistema advierte que se marcaron Blocked sin causa válida y el Blocked descartado permanece en el historial (RN-058, DEC-045).

• Error E1 — Blocked sin bloqueo. El sistema impide registrar el resultado Blocked si

no se asocia un bloqueo (RN-039).

Datos y campos (funcional)

• Captura el usuario: tipo, descripción, responsable, impacto.
• Deriva el sistema: ejecuciones y escenarios vinculados, estado del bloqueo, marcas de

tiempo de cada transición.

Reglas de negocio aplicables

• RN-039 — un resultado Blocked exige un bloqueo asociado.
• RN-057 — el bloqueo es una entidad con dueño y ciclo de vida propio.
• RN-058 / DEC-045 — al descartar un bloqueo las ejecuciones vuelven a Not run, y el

Blocked inválido queda registrado como señal de mal uso.

Estados y transiciones. Sigue la máquina de estados del bloqueo: Abierto → En gestión → Resuelto, con salida lateral Descartado.

Eventos que emite. blocker.created, test_case.blocked, blocker.resolved.

Criterios de aceptación

• CA-275

> Dado una ejecución que el usuario marca como Blocked > Cuando confirma el resultado sin asociar ningún bloqueo > Entonces el sistema lo impide y exige crear o seleccionar un bloqueo.

• CA-276

> Dado un impedimento real > Cuando el QA crea un bloqueo con tipo, descripción, responsable e impacto > Entonces el bloqueo queda Abierto, vinculado a la ejecución, y se emiten blocker.created y test_case.blocked.

• CA-277

> Dado un bloqueo Abierto o En gestión asociado a varias ejecuciones > Cuando se marca Resuelto > Entonces todas las ejecuciones dependientes pasan a Retest required y se emite blocker.resolved.

• CA-278

> Dado un bloqueo que se determina que no era real > Cuando se descarta > Entonces las ejecuciones asociadas vuelven a Not run, el sistema advierte el uso indebido de Blocked y el estado descartado queda en el historial.

Dependencias y bloqueos

• HU-016 (ejecución guiada) origina el Blocked que dispara esta HU.
• HU-018 (reejecución) consume las ejecuciones liberadas a Retest required.

Casos borde / notas. Un bloqueo resuelto no reabre por sí solo; si el impedimento reaparece se registra un bloqueo nuevo. La diferencia entre descartar (nunca fue bloqueo) y resolver (dejó de serlo) es la que decide si las ejecuciones van a Not run o a Retest required.