141RF50RNF85RN18CU27HU60DEC19PA

Casos de uso

CU-005 a CU-011 · Casos y plan

docs/01-requerimientos/casos-de-uso/cu-casos-y-plan.md · 275 líneas

Casos de uso — Casos de uso, plan de pruebas y ambiente

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

CU-005 — Generar casos de uso con IA

Actor principal: QA Objetivo: convertir el requerimiento analizado en casos de uso estructurados y revisables. Cubre: RF-029, RF-031, RF-032, RF-124, RF-126 · Reglas: RN-020, RN-021, RN-064

Precondiciones

  • El requerimiento fue analizado (CU-004) o al menos tiene documento de origen.

Flujo principal

  1. El usuario solicita la generación de casos de uso desde el requerimiento.
  2. El sistema encola el job y avisa que el resultado llegará de forma asíncrona.
  3. Al completarse, el sistema presenta los casos propuestos, cada uno con objetivo,

actores, precondiciones, flujo principal, flujos alternativos, flujos de error y postcondiciones.

  1. Cada caso propuesto queda marcado de forma visible como generado por IA y en estado

Draft.

  1. El usuario revisa, edita y descarta lo que corresponda.
  2. El sistema registra en cada caso el requerimiento de origen y el job que lo produjo.
  3. El sistema emite use_case.generated.

Flujos alternativos

  • A1 — Generación parcial. El usuario acepta algunos casos y descarta otros. Solo los

aceptados se persisten.

  • A2 — Regenerar. El usuario pide una nueva propuesta. Los casos ya aceptados no se

ven afectados.

Flujos de error

  • E1 — El proveedor de IA falla. El sistema informa tras los reintentos acotados. El

usuario puede continuar con CU-006.

  • E2 — Propuesta incompleta. Un caso propuesto sin los campos obligatorios se persiste

en Draft, pero el sistema impide avanzarlo a En revisión hasta completarlo (RN-020).

Postcondiciones

  • Existen casos de uso en Draft, trazados a su requerimiento y a su job de IA.

CU-006 — Crear un caso de uso manualmente

Actor principal: QA Objetivo: definir un caso de uso sin depender de la IA. Cubre: RF-030, RF-031, RF-032 · Reglas: RN-020, RN-021, RN-065

Precondiciones

  • Existe un requerimiento en el proyecto al cual asociar el caso.

Flujo principal

  1. El usuario crea un caso de uso en blanco y selecciona el requerimiento de origen.
  2. El usuario completa objetivo, actores, precondiciones, flujo principal, flujos

alternativos, flujos de error, postcondiciones, reglas aplicables y supuestos.

  1. El sistema guarda el caso en Draft.
  2. Cuando los campos obligatorios están completos, el usuario lo envía a En revisión.

Flujos alternativos

  • A1 — Partir de una propuesta de IA. El usuario toma un caso generado y lo reescribe

por completo. Conserva la trazabilidad al job, con la anotación de que fue reescrito.

Flujos de error

  • E1 — Campos obligatorios incompletos. El sistema impide la transición a

En revisión y señala qué falta (RN-020).

Postcondiciones

  • El caso existe con la misma estructura y trazabilidad que uno generado por IA. La vía de

creación no cambia sus obligaciones.

CU-007 — Revisar y congelar un caso de uso

Actor principal: Product Manager Objetivo: fijar una versión aprobada como línea base inmutable, para que las pruebas y la evidencia se anclen a una definición estable. Cubre: RF-033, RF-034, RF-035, RF-036, RF-037, RF-042 · Reglas: RN-009, RN-022, RN-025

Precondiciones

  • El caso de uso está en estado En revisión o Validado.
  • El usuario tiene rol Product Manager en el proyecto.

Flujo principal

  1. El PM abre el caso de uso y revisa su contenido, sus supuestos y las preguntas abiertas

heredadas del requerimiento.

  1. El PM marca el caso como Validado.
  2. El PM ejecuta la acción de congelar.
  3. El sistema pide confirmación explicando que la versión quedará inmutable y que

cualquier cambio posterior exigirá crear una versión nueva.

  1. El PM confirma.
  2. El sistema pasa el caso a Congelado y registra quién congeló, cuándo y sobre qué

número de versión, de forma inmutable.

  1. El sistema emite use_case.frozen.

Flujos alternativos

  • A1 — Devolver a revisión. El PM detecta un problema y devuelve el caso a

En revisión en lugar de congelarlo.

  • A2 — Declarar obsoleto. El PM marca un caso congelado como Obsoleto. Los

escenarios derivados se marcan como desactualizados y el caso deja de contar para la cobertura.

Flujos de error

  • E1 — El usuario no es Product Manager. El sistema no ofrece la acción y la rechaza

si se intenta por API (RN-022).

  • E2 — Intento de editar un caso congelado. El sistema lo rechaza en cualquier

circunstancia y ofrece crear una versión nueva (RN-009, CU-008).

Postcondiciones

  • Existe una versión congelada, inmutable y consultable para siempre.
  • Los escenarios de prueba ya pueden generarse desde este caso (RN-031).

CU-008 — Crear una versión nueva de un caso congelado

Actor principal: QA Objetivo: reflejar un cambio del negocio sin destruir la línea base contra la cual ya se probó. Cubre: RF-038, RF-039, RF-040, RF-042 · Reglas: RN-023, RN-024, RN-025, RN-037

Precondiciones

  • Existe un caso de uso en estado Congelado.

Flujo principal

  1. El usuario abre el caso congelado y solicita crear una versión nueva.
  2. El sistema crea la versión siguiente en estado Draft, con el contenido heredado.
  3. El usuario edita lo que cambió.
  4. La versión nueva recorre el ciclo normal hasta congelarse (CU-007).
  5. Al congelarse, el sistema marca como desactualizados todos los escenarios derivados

de la versión anterior.

  1. El sistema deja visible, en cada escenario afectado, qué versión lo originó y cuál es

la vigente.

Flujos alternativos

  • A1 — Revisar un escenario desactualizado. El usuario compara el escenario con la

versión vigente del caso, confirma que sigue siendo correcto y limpia el indicador. El escenario no cambia de estado.

  • A2 — El escenario debe cambiar. El usuario lo devuelve a Requiere cambios y lo

ajusta.

Flujos de error

  • E1 — Ya existe una versión en curso. Si el caso tiene una versión posterior en

Draft o En revisión, el sistema lo indica y ofrece continuarla en lugar de abrir otra.

Postcondiciones

  • Ambas versiones coexisten: la congelada intacta, la nueva en curso.
  • Los escenarios afectados están marcados para revisión, pero siguen siendo ejecutables

con advertencia (RN-037).

CU-009 — Generar el plan de pruebas y sus escenarios

Actor principal: QA Objetivo: convertir los casos de uso congelados en escenarios ejecutables por cualquiera. Cubre: RF-043, RF-044, RF-045, RF-046, RF-047, RF-048, RF-049, RF-054, RF-055, RF-056 · Reglas: RN-031, RN-032, RN-036

Precondiciones

  • Existe al menos un caso de uso en estado Congelado.

Flujo principal

  1. El usuario abre el plan de pruebas del proyecto y selecciona los casos de uso

congelados a cubrir.

  1. El usuario solicita la generación de escenarios.
  2. El sistema propone escenarios con objetivo, precondiciones, ambiente requerido, datos

de prueba, rol necesario, pasos numerados con resultado esperado, criterio de aprobación, evidencia requerida y tipo de ejecución.

  1. El usuario revisa, edita, agrega escenarios a mano y descarta los que no aplican.
  2. El usuario define criterios de aceptación y prioriza por riesgo o impacto.
  3. El sistema actualiza la matriz de cobertura y señala los casos de uso congelados sin

escenario que los cubra.

  1. El usuario envía los escenarios a En revisión y luego a Aprobado.
  2. El sistema emite test_plan.generated.

Flujos alternativos

  • A1 — Revisión asistida del plan. El usuario pide a la IA que señale casos borde no

cubiertos o criterios de aceptación ambiguos, y evalúa las sugerencias.

  • A2 — Escenario íntegramente manual. El usuario crea un escenario sin pasar por la

IA, con las mismas obligaciones estructurales.

Flujos de error

  • E1 — Caso de uso no congelado. El sistema impide generar escenarios desde un caso

que no esté en Congelado, explicando por qué (RN-031).

  • E2 — Escenario incompleto. El sistema impide aprobar un escenario al que le falte

cualquier campo obligatorio, y señala cuáles (RN-032).

Postcondiciones

  • Existe un plan con escenarios aprobados y una matriz de cobertura que muestra los huecos.

CU-010 — Aprobar el plan de pruebas

Actor principal: Product Manager Objetivo: dar por bueno que lo que se va a probar responde al requerimiento. Cubre: RF-051, RF-052, RF-053 · Reglas: RN-033, RN-034, RN-035

Precondiciones

  • El plan está en Pendiente de aprobación con al menos un escenario aprobado.

Flujo principal

  1. El PM revisa el plan: escenarios, criterios de aceptación, prioridades y matriz de

cobertura.

  1. El sistema destaca los casos de uso congelados sin cobertura.
  2. El PM aprueba el plan.
  3. El sistema pasa el plan a Aprobado, habilitando la apertura de ciclos.
  4. El sistema emite test_plan.approved.

Flujos alternativos

  • A1 — Devolver con observaciones. El PM devuelve el plan a Borrador indicando qué

falta. Los escenarios conservan sus estados individuales.

  • A2 — Aprobar con huecos conocidos. El PM aprueba aunque haya casos sin cobertura. El

sistema lo permite, pero deja constancia de qué quedó descubierto al momento de aprobar.

Flujos de error

  • E1 — El usuario no es Product Manager. El sistema rechaza la aprobación (RN-033).
  • E2 — Se modifica un plan aprobado. Agregar o cambiar un escenario devuelve el plan a

Pendiente de aprobación, indicando qué cambió. Los ciclos ya abiertos continúan (RN-035).

Postcondiciones

  • El plan está aprobado y sus escenarios son ejecutables (RN-034).

CU-011 — Registrar y preparar un ambiente de prueba

Actor principal: QA Objetivo: dejar por escrito todo lo necesario para ejecutar el plan y poder reproducir la ejecución después. Cubre: RF-057 a RF-067 · Reglas: RN-026, RN-027, RN-028, RN-029, RN-030

Precondiciones

  • El usuario tiene rol en el proyecto.

Flujo principal

  1. El usuario registra un ambiente y elige su tipo: Local, Desarrollo, QA,

Staging, Producción controlada o Servidor externo.

  1. Registra URLs, endpoints y servidores.
  2. Declara las credenciales necesarias como referencias al vault: identificador del

secreto, ubicación y responsable de entregarlo.

  1. Registra conexiones: base de datos, APIs internas y externas, autenticación, storage,

colas y terceros.

  1. Registra la configuración de ejecución: variables, feature flags, parámetros por

cliente, versiones de servicios y la referencia de código bajo prueba — branch, commit, tag o release candidate.

  1. Documenta los datos de prueba: usuarios, roles, permisos, registros base, fixtures y

seeds.

  1. Documenta las dependencias previas: migraciones, jobs, integraciones, servicios

levantados y accesos validados.

  1. Recorre el checklist de readiness y marca cada verificación.

Flujos alternativos

  • A1 — Clonar un ambiente. El usuario duplica un ambiente existente del mismo proyecto

y ajusta lo que cambia.

  • A2 — Actualizar la versión bajo prueba. Entre un ciclo y otro se actualiza el commit

o release candidate. Los ciclos ya abiertos conservan su snapshot (RN-029).

Flujos de error

  • E1 — Secreto en texto plano. El sistema detecta un valor que aparenta ser una

credencial y rechaza el guardado, explicando que solo se admiten referencias (RN-027).

  • E2 — Checklist incompleto al abrir un ciclo. El sistema advierte, no bloquea, y deja

constancia del estado del checklist en el ciclo (RN-028).

Postcondiciones

  • El ambiente está documentado y listo para que un ciclo capture su snapshot. El ambiente

no se versiona: el registro histórico es el snapshot del ciclo (RN-029, DEC-046).

  • No existe ningún valor de credencial almacenado en Argos QA (RN-012).