141RF50RNF85RN18CU27HU60DEC19PA

Casos de uso

CU-012 a CU-018 · Ejecución y cierre

docs/01-requerimientos/casos-de-uso/cu-ejecucion-y-cierre.md · 300 líneas

Casos de uso — Ejecución, defectos y cierre

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

CU-012 — Abrir un ciclo de QA

Actor principal: QA Objetivo: delimitar una iteración de pruebas sobre un ambiente concreto, para que sus resultados signifiquen algo comparable. Cubre: RF-068, RF-069, RF-066, RF-067 · Reglas: RN-028, RN-029

Precondiciones

  • El plan de pruebas está Aprobado.
  • Existe al menos un ambiente registrado.

Flujo principal

  1. El usuario abre un ciclo indicando nombre y objetivo.
  2. Selecciona el ambiente contra el que se ejecutará.
  3. Selecciona los escenarios aprobados que componen el alcance del ciclo.
  4. El sistema muestra el estado del checklist de readiness del ambiente.
  5. El usuario confirma la apertura.
  6. El sistema captura un snapshot inmutable de la configuración del ambiente y lo asocia

al ciclo.

  1. Todos los escenarios del alcance quedan en Not run.

Flujos alternativos

  • A1 — Ciclo de regresión. El usuario selecciona escenarios de casos de uso ya

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

  • A2 — Escenarios desactualizados en el alcance. El sistema advierte cuáles están

marcados como desactualizados y permite continuar (RN-037).

Flujos de 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).

  • E2 — Checklist incompleto. El sistema advierte y registra el estado del checklist en

el ciclo. No bloquea (RN-028).

Postcondiciones

  • Existe un ciclo Abierto con alcance definido y snapshot de ambiente congelado.

CU-013 — Ejecutar un escenario de forma guiada

Actor principal: Developer Objetivo: que una persona sin conocimiento previo del proyecto pueda validar con el mismo criterio que cualquier otra. Es el caso de uso central del producto. Cubre: RF-070, RF-071, RF-072, RF-073, RF-074, RF-075, RF-076, RF-079, RF-083 a RF-088 · Reglas: RN-013, RN-038, RN-040, RN-042, RN-043, RN-046, RN-047

Precondiciones

  • El escenario está Aprobado dentro de un plan aprobado.
  • El usuario tiene rol en el proyecto.

Flujo principal

  1. El usuario abre un escenario del ciclo activo.
  2. El sistema presenta las precondiciones, el ambiente requerido, los datos de prueba y el

rol necesario.

  1. El usuario confirma que las precondiciones se cumplen.
  2. El sistema presenta el primer paso con su resultado esperado.
  3. El usuario ejecuta el paso en el sistema bajo prueba y registra el resultado observado.
  4. El usuario adjunta la evidencia del paso: screenshot, log o archivo.
  5. El sistema repite desde el paso 4 hasta agotar los pasos.
  6. El sistema propone el resultado global según los resultados por paso y el criterio de

aprobación. Si quedaron pasos No ejecutado, el resultado global no puede ser Pass (RN-043, RN-084).

  1. El usuario confirma el resultado global y adjunta la evidencia final si corresponde.
  2. 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.

Flujos alternativos

  • A1 — Ejecución fuera de ciclo. El usuario ejecuta un escenario aprobado sin un ciclo

abierto, para una verificación puntual. Elige el ambiente entre los del proyecto compatibles con el que exige el escenario; si no hay ninguno, el sistema lo impide (RN-080). El sistema captura su propio snapshot del ambiente elegido y marca la ejecución como fuera de ciclo: se registra con trazabilidad y evidencia completas, pero no computa en cobertura ni avance (RN-038, RN-062).

  • A2 — Interrupción. El usuario cierra la pestaña a mitad de la ejecución. Al volver,

el sistema restaura el progreso registrado hasta ese punto (RNF-034).

  • A3 — Un paso falla. El usuario marca el paso como Fail y continúa o detiene la

ejecución. Si la detiene, debe cerrarla igual con resultado Fail o Blocked, y los pasos restantes quedan No ejecutado (RN-084). El resultado global no puede ser Pass (RN-043). Desde ese punto puede invocar CU-014.

  • A4 — Impedimento para probar. El usuario marca la ejecución como Blocked, lo que

exige asociar un bloqueo (CU-015).

Flujos de error

  • E1 — Intento de registrar sin evidencia. El sistema rechaza el registro, en

cualquier resultado, incluido Pass. Es la regla que sostiene la diferencia entre validar y afirmar (RN-013, RN-046).

  • E2 — Fallo al subir la evidencia a S3. 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 (RNF-013).

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

Postcondiciones

  • Existe un registro de ejecución inmutable con su evidencia, contexto y trazabilidad.
  • Si el resultado fue Fail o Blocked, se emite test_case.failed o

test_case.blocked.

CU-014 — Registrar un bug desde un fallo

Actor principal: Developer Objetivo: dejar un defecto reproducible y trazado hasta el requerimiento que lo originó, y ponerlo en el flujo de trabajo del equipo. Cubre: RF-077, RF-092 a RF-100 · Reglas: RN-051, RN-052, RN-053, RN-054, RN-056

Precondiciones

  • Existe una ejecución con al menos un paso en Fail.

Flujo principal

  1. Desde el paso fallido, el usuario crea un bug.
  2. El sistema precarga automáticamente el contexto: escenario, caso de uso, paso, ciclo,

ambiente, snapshot de configuración, referencia de código bajo prueba, ejecutor, timestamp y la evidencia ya adjunta. Este contexto no es editable.

  1. El usuario completa título, descripción, severidad, pasos para reproducir, resultado

esperado y resultado obtenido.

  1. El usuario adjunta evidencia adicional si la tiene.
  2. El sistema guarda el bug en estado Nuevo con sincronización Pendiente.
  3. El sistema crea el ticket espejo en Argos Operaciones y enlaza ambos de forma permanente.
  4. La sincronización pasa a Sincronizado.
  5. El sistema emite bug.created.

Flujos alternativos

  • A1 — Bug independiente. El usuario registra un bug sin partir de una ejecución. Debe

aportar manualmente el contexto que no se puede heredar, y sigue rigiendo la exigencia de evidencia (RN-052).

  • A2 — Asignación. El usuario asigna el bug a un miembro del proyecto con rol PM, QA o

Developer — nunca a un Client (RN-083). El bug pasa a Asignado. El sistema emite bug.assigned y notifica.

Flujos de error

  • E1 — Argos Operaciones no responde. El bug queda guardado localmente con sincronización

Pendiente y el sistema reintenta de forma automática y acotada. El ejecutor no pierde el hallazgo ni queda bloqueado (RN-054).

  • E2 — Reintentos agotados. La sincronización pasa a Error, visible en el bug, con

la opción de forzar el reintento manualmente.

  • E3 — Bug sin evidencia. El sistema rechaza el registro (RN-052).

Postcondiciones

  • El bug existe con su cadena de trazabilidad completa hasta el requerimiento.
  • El ticket en Argos Operaciones existe y está enlazado, o quedó encolado para reintento.

CU-015 — Registrar y resolver un bloqueo

Actor principal: QA Objetivo: distinguir lo que impide probar de lo que está defectuoso, para que ninguna de las dos cosas contamine la lectura de la otra. Cubre: RF-078, RF-101 a RF-105 · Reglas: RN-039, RN-057, RN-058

Precondiciones

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

Flujo principal

  1. Al marcar una ejecución como Blocked, el sistema exige asociar un bloqueo.
  2. El usuario crea uno nuevo o selecciona uno existente.
  3. Al crearlo, indica tipo — Ambiente, Datos, Acceso, Dependencia externa,

Definición pendiente —, descripción, responsable e impacto.

  1. El sistema guarda el bloqueo en estado Abierto y lo vincula a la ejecución.
  2. El sistema emite blocker.created y test_case.blocked.
  3. Cuando alguien se hace cargo, el bloqueo pasa a En gestión.
  4. Al desaparecer el impedimento, se marca Resuelto.
  5. El sistema pasa automáticamente a Retest required todas las ejecuciones que dependían

de él, y emite blocker.resolved.

Flujos alternativos

  • A1 — Bloqueo con alcance múltiple. Un mismo bloqueo se asocia a varias ejecuciones y

escenarios. Al resolverse, todos se liberan a la vez.

  • A2 — Bloqueo descartado. Se determina que no era un bloqueo real. Las ejecuciones

vuelven a Not run, no a Retest required: si el impedimento nunca existió, no hay nada que retestear. El sistema advierte que se marcaron Blocked sin causa válida — es una señal de mal uso del estado, no un evento neutro — y el Blocked descartado permanece en el historial de la ejecución. RN-058, DEC-045.

Flujos de error

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

se asocia un bloqueo (RN-039).

Postcondiciones

  • El impedimento está registrado como entidad con dueño, no diluido en un comentario.
  • Al resolverse, las ejecuciones afectadas quedan listas para reejecución.

CU-016 — Reejecutar tras una corrección

Actor principal: Developer Objetivo: confirmar con evidencia que la corrección funciona, sin perder el registro de que antes falló. Cubre: RF-079, RF-080, RF-098, RF-099 · Reglas: RN-040, RN-041, RN-044, RN-055

Precondiciones

  • Existe un bug en estado Listo para retest, o un bloqueo recién resuelto.

Flujo principal

  1. El desarrollador marca el bug como Listo para retest.
  2. El sistema emite bug.ready_for_retest y pasa a Retest required las ejecuciones

fallidas que lo originaron.

  1. El ejecutor abre el escenario y lo ejecuta nuevamente, siguiendo CU-013.
  2. El sistema crea un registro de ejecución nuevo; el anterior se conserva intacto.
  3. Si el resultado es conforme, el escenario queda en Passed after fix y el bug puede

pasar a Resuelto.

Flujos alternativos

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

Reabierto. El sistema emite bug.reopened.

  • A2 — Aparece un impedimento nuevo. El escenario pasa a Blocked con su bloqueo

asociado (CU-015).

  • A3 — Reapertura tardía. Un bug ya Cerrado reaparece. La reapertura exige motivo y

evidencia nueva (RN-055).

Flujos de error

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

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

Postcondiciones

  • El historial muestra el fallo y su posterior aprobación, ambos con evidencia.
  • Passed after fix distingue esta aprobación de una que pasó a la primera.

CU-017 — Cerrar el ciclo y emitir el reporte de calidad

Actor principal: QA Objetivo: dar por terminada la iteración y dejar una foto defendible del estado de calidad. Cubre: RF-081, RF-082, RF-106 a RF-113 · Reglas: RN-045, RN-059, RN-060, RN-062, RN-063

Precondiciones

  • Existe un ciclo Abierto.

Flujo principal

  1. El usuario solicita cerrar el ciclo.
  2. El sistema muestra el resumen: escenarios aprobados, fallidos, bloqueados y sin

ejecutar; bugs abiertos por severidad; bloqueos activos; huecos de cobertura de diseño.

  1. Si quedan escenarios en Not run, Retest required o Blocked, el sistema lo advierte

y exige confirmación explícita.

  1. El usuario confirma.
  2. El sistema cierra el ciclo y emite cycle.completed.
  3. El usuario genera el reporte formal de calidad.
  4. El sistema produce el reporte con alcance, resultados, cobertura de diseño y ejecutada, evidencia

referenciada, bugs pendientes y señales de riesgo de liberación, anclado a las versiones congeladas de los casos de uso vigentes en ese momento.

  1. El sistema emite quality_report.generated.

Flujos alternativos

  • A1 — Reabrir el ciclo. El usuario reabre un ciclo cerrado. El sistema registra quién

y por qué (RN-045). El reporte ya emitido no se altera.

  • A2 — Reporte intermedio. El usuario genera un reporte sin cerrar el ciclo, marcado

como parcial.

Flujos de error

  • E1 — Fallo al generar el reporte. El sistema informa y conserva el ciclo cerrado. El

reporte puede regenerarse.

Postcondiciones

  • El ciclo está cerrado con su resultado consolidado.
  • Existe un reporte inmutable en contenido: una versión nueva de un caso de uso posterior

al reporte no cambia lo que el reporte dice (RN-063).

CU-018 — Consultar el reporte agregado como Client

Actor principal: Client Objetivo: dar visibilidad del estado de calidad a la contraparte externa sin exponer material interno. Cubre: RF-114, RF-015, RF-006 · Reglas: RN-004, RN-006, RN-061

Precondiciones

  • El usuario tiene rol Client en el proyecto.

Flujo principal

  1. El usuario ingresa y ve únicamente los proyectos donde tiene rol Client.
  2. Abre el proyecto y accede al reporte agregado de calidad.
  3. El sistema muestra cobertura ejecutada (RF-107), porcentaje de éxito, avance del ciclo y conteo de bugs por

severidad.

  1. El usuario puede exportar exactamente ese mismo nivel de detalle.

Flujos alternativos

  • A1 — Sin ciclos ejecutados. El sistema indica que aún no hay resultados, sin exponer

la estructura interna del proyecto.

Flujos de error

  • E1 — Acceso directo a un recurso interno. Un intento de acceder por identificador a

un caso de uso, escenario, evidencia, comentario o detalle de bug se rechaza en el backend, no ocultándolo en la interfaz (RNF-028, RN-061).

  • E2 — Proyecto sin rol asignado. El sistema responde como si el proyecto no existiera

(RN-004).

Postcondiciones

  • El cliente conoce el estado de calidad de su proyecto.
  • Ningún material interno — evidencia, comentarios, descripciones de bugs — quedó expuesto.