Épica E — Plan de pruebas y escenarios

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

Cubre la conversión de casos de uso congelados en escenarios ejecutables, la matriz de cobertura de diseño y la aprobación del plan por el Product Manager. Reglas de negocio del bloque: RN-031 a RN-036.

HU-012 — Generar el plan de pruebas y sus escenarios

Épica: E · Plan de pruebas y escenarios · Deriva de: CU-009 · Cubre: RF-043–RF-050, RF-054–RF-056, RF-139 · Reglas: RN-031, RN-032, RN-036 · Estado: Borrador

Historia

Como QA, quiero convertir los casos de uso congelados en escenarios ejecutables, con su criterio de aprobación y su matriz de cobertura, para que cualquiera pueda probar contra una definición estable y se vea qué quedó sin cubrir.

Objetivo / valor. Que la prueba se ancle a una línea base inmutable: solo se generan escenarios desde casos Congelado, cada escenario nace estructurado y con criterio de aprobación, y la matriz muestra los huecos de cobertura de diseño antes de que alguien los descubra ejecutando.

Alcance

• Dentro: generación asistida de escenarios desde casos congelados, edición y creación

manual, criterios de aceptación, priorización por riesgo o impacto, matriz de cobertura de diseño y detección de huecos, y el avance de escenarios por sus estados.

• Fuera: la aprobación del plan (HU-013), la ejecución (HU-016) y el diseño del prompt de

generación de escenarios (documentado en HU-026, no diseñado aquí).

Actores y permisos

Precondiciones

• Existe al menos un caso de uso en estado Congelado en el proyecto.
• El proyecto tiene un plan de pruebas (uno por proyecto, RF-043).

Comportamiento funcional

• Principal. El QA abre el plan del proyecto y selecciona los casos de uso Congelado a

cubrir; solicita la generación. El sistema propone escenarios —cada uno 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— en estado Generado y marcados como generados por IA. El usuario revisa, edita, agrega escenarios a mano y descarta los que no aplican; define criterios de aceptación y prioriza por riesgo o impacto. El sistema actualiza la matriz de cobertura y señala los casos congelados sin escenario que los cubra. El usuario envía los escenarios a En revisión. El sistema emite test_plan.generated.

• Alternativo 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, como propuesta revisable; evalúa y acepta o descarta las sugerencias.

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

la IA, con las mismas obligaciones estructurales (RF-046, RF-047).

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

que no esté en Congelado y explica por qué (RN-031).

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

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

Datos y campos (funcional, no esquema)

• Del escenario: objetivo, precondiciones, ambiente requerido, datos de prueba, rol o

usuario necesario, pasos numerados con resultado esperado por paso, criterio de aprobación, evidencia requerida, tipo de ejecución (Manual, Automatizable, Semi-automatizada, No automatizable — informativo en el MVP), prioridad por riesgo o impacto, y el caso de uso de origen con su número de versión.

• De la matriz de cobertura de diseño: relación caso de uso ↔ escenarios que lo cubren, en

ambos sentidos; lista de casos congelados sin escenario aprobado que los cubra.

• Precarga la IA: la propuesta inicial de escenarios y de criterios de aceptación; todo es

editable y descartable.

Reglas de negocio aplicables

• RN-031 — un escenario solo pasa a Aprobado si su caso de uso de origen está

Congelado; la exigencia es del escenario, no del método. Crear y editar antes de eso está permitido: el escenario espera en Generado o En revisión.

• RN-032 — un escenario incompleto no puede aprobarse; se señalan los campos faltantes.
• RN-036 — un caso congelado sin ningún escenario aprobado que lo cubra es un hueco de

cobertura de diseño y se reporta como tal.

Estados y transiciones. Sigue la máquina de estados del escenario: Generado → En revisión → Aprobado, con Requiere cambios y Retirado. Desactualizado no es un estado sino un indicador que acompaña a cualquier estado (RN-037). El plan sigue su propia máquina: Borrador → Pendiente de aprobación → Aprobado.

Integraciones (documentado, el dev implementa)

• IA (orquestación, HU-026) — genera la propuesta de escenarios y de criterios de

aceptación de forma asíncrona; el comportamiento del plan no depende de que la IA responda, porque todo escenario admite creación manual.

Eventos que emite. test_plan.generated.

Criterios de aceptación

• CA-140

> Dado un caso de uso en estado Congelado seleccionado en el plan > Cuando el QA solicita la generación de escenarios > Entonces el sistema propone escenarios en estado Generado, marcados como generados por IA, cada uno con objetivo, precondiciones, ambiente requerido, datos de prueba, rol necesario, pasos con resultado esperado, criterio de aprobación, evidencia requerida y tipo de ejecución.

• CA-141

> Dado un caso de uso que no está en estado Congelado > Cuando se intenta generar escenarios a partir de él > Entonces el sistema lo impide y explica que solo se generan escenarios desde casos de uso congelados.

• CA-142

> Dado un escenario al que le falta al menos un campo obligatorio > Cuando se intenta pasarlo a Aprobado > Entonces el sistema lo impide y señala qué campos faltan.

• CA-143

> Dado un escenario completo cuyo caso de uso de origen no está en Congelado > Cuando se intenta pasarlo a Aprobado > Entonces el sistema lo impide e indica qué caso de uso falta congelar, aunque el escenario se haya creado a mano.

• CA-144

> Dado un caso de uso congelado sin ningún escenario aprobado que lo cubra > Cuando se consulta la matriz de cobertura > Entonces la matriz muestra la relación caso de uso ↔ escenarios en ambos sentidos y señala explícitamente ese caso como hueco de cobertura de diseño.

• CA-145

> Dado un conjunto de escenarios revisados sobre casos congelados > Cuando el usuario los envía a revisión tras la generación > Entonces el sistema emite test_plan.generated.

Dependencias y bloqueos

• HU-010 (revisar y congelar un caso de uso) provee los casos Congelado que esta HU

exige.

• HU-011 (versión nueva de un caso congelado) marca escenarios como desactualizados

(RN-024, RN-037); el indicador se gestiona aquí.

• HU-013 (aprobar el plan) consume los escenarios en Aprobado.
• HU-026 (orquestación de IA) provee la generación asistida.

Casos borde / notas. El tipo de ejecución es informativo en el MVP: no habilita automatización, que es [Fase 3]. La matriz mide cobertura de diseño —si existe prueba diseñada—, no si se ejecutó (RF-054, DEC-049).

HU-013 — Aprobar el plan de pruebas

Épica: E · Plan de pruebas y escenarios · Deriva de: CU-010 · Cubre: RF-051–RF-053 · Reglas: RN-033, RN-034, RN-035 · Estado: Borrador

Historia

Como Product Manager, quiero aprobar el plan de pruebas antes de que se ejecute, para dar por bueno que lo que se va a probar responde al requerimiento y habilitar la apertura de ciclos.

Objetivo / valor. La IA propone y el equipo itera, pero la ejecución solo arranca cuando el PM aprueba. Modificar un plan aprobado lo devuelve a aprobación sin frenar lo que ya está en curso.

Alcance

• Dentro: la revisión y aprobación del plan por el PM, la aprobación con huecos conocidos,

la devolución con observaciones y la reapertura automática al modificar un plan aprobado.

• Fuera: la generación y edición de escenarios (HU-012), la apertura de ciclos (HU-015) y

la ejecución (HU-016).

Actores y permisos

Precondiciones

• El plan está en Pendiente de aprobación con al menos un escenario en Aprobado.
• El usuario tiene rol Product Manager en el proyecto.

Comportamiento funcional

• Principal. El PM revisa escenarios, criterios de aceptación, prioridades y matriz de

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

• Alternativo A1 — devolver con observaciones. El PM devuelve el plan a Borrador

indicando qué falta; los escenarios conservan sus estados individuales.

• Alternativo A2 — aprobar con huecos conocidos. El PM aprueba aunque haya casos sin

cobertura; el sistema lo permite y deja constancia de qué quedó descubierto al momento de aprobar.

• Error E1 — el usuario no es Product Manager. El sistema rechaza la aprobación (RN-033).
• Error 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).

Datos y campos (funcional)

• Captura el PM: la decisión de aprobar o devolver, y —en la devolución— las observaciones.
• Deriva el sistema: el estado del plan, la constancia de los huecos conocidos al momento de

aprobar y el registro de qué cambió al reabrirse.

Reglas de negocio aplicables

• RN-033 — solo el Product Manager aprueba el plan; habilita la ejecución.
• RN-034 — solo se ejecutan escenarios en Aprobado dentro de un plan aprobado; la

apertura de un ciclo exige plan aprobado.

• RN-035 — agregar o modificar escenarios en un plan aprobado lo devuelve a

Pendiente de aprobación; los ciclos ya abiertos siguen con los escenarios que estaban aprobados al abrirse.

Estados y transiciones. Sigue la máquina de estados del plan de pruebas: Pendiente de aprobación → Aprobado (aprueba el PM) y Aprobado → Pendiente de aprobación (se agrega o modifica un escenario). La devolución con observaciones lleva a Borrador.

Eventos que emite. test_plan.approved.

Criterios de aceptación

• CA-146

> Dado un plan en Pendiente de aprobación con al menos un escenario Aprobado > Cuando el Product Manager lo aprueba > Entonces el plan pasa a Aprobado, queda habilitada la apertura de ciclos y se emite test_plan.approved.

• CA-147

> Dado un usuario que no es Product Manager > Cuando intenta aprobar el plan > Entonces el sistema rechaza la aprobación.

• CA-148

> Dado un plan en estado Aprobado con uno o más ciclos abiertos > Cuando se agrega o modifica un escenario > Entonces el plan vuelve a Pendiente de aprobación indicando qué cambió, y los ciclos ya abiertos continúan.

• CA-149

> Dado un plan con casos de uso congelados sin cobertura de diseño > Cuando el Product Manager aprueba a pesar de los huecos > Entonces el sistema lo permite y deja constancia de qué quedó descubierto al momento de aprobar.

Dependencias y bloqueos

• HU-012 (generar el plan) provee los escenarios Aprobado que la aprobación exige.
• HU-015 (abrir un ciclo) depende de que el plan esté Aprobado (RN-034).

Casos borde / notas. Un plan aprobado que vuelve a Pendiente de aprobación no interrumpe los ciclos en curso ni impide la ejecución fuera de ciclo de un escenario que siga Aprobado (RN-034, DEC-055); lo único que se bloquea es abrir un ciclo nuevo.