Casos de Prueba Sprint 1 - Davidcuama/via-coinogas GitHub Wiki

Casos de Prueba — Sprint 1

Casos de prueba (CP) del sistema VIA Compras en formato Dado/Cuando/Entonces. Cada CP enlaza su historia de usuario y la prueba automática que lo cubre, para garantizar la coherencia entre pruebas automáticas y casos de prueba.

Tabla resumen de trazabilidad

CP	Título	HU	Tipo	Prueba automática
CP-01	Formulario en blanco	HU-01	Escenario / Unitaria	`BorradorRequerimientoTests`, `RequerimientoModelTests`
CP-02	Validación de campos obligatorios	HU-15	Integración (vista)	`ValidacionCamposObligatoriosTests` (9)
CP-03	Guardar y reanudar borradores	HU-18	Integración (sesión)	`BorradorRequerimientoTests` (22)
CP-04	Radicación y consecutivo	HU-16, HU-17	Flujo completo + Concurrencia	`ConsecutivoRadicacionTests`, `ConsecutivoConcurrenciaTests`, `ConfirmacionRadicacionTests`
CP-05	Responsive móvil/escritorio	—	Manual + unitaria viewport	`IdentidadVisualTests.test_declara_el_viewport`
CP-06	Descarte de borrador	HU-18	Integración	`BorradorRequerimientoTests`
CP-07	Portada pública	—	Escenario	`PortadaTests` (4)
CP-08	Ingreso y enrutamiento por perfil	—	Integración	`IngresoTests` (8), `PerfilesTests` (4)
CP-09	Aislamiento entre solicitantes	HU-16	Integración (seguridad)	`AutoriaRequerimientoTests` (4), `BandejaTests` (5)

CP-01 · Carga inicial del formulario en blanco — HU-01

Dado que un solicitante autenticado abre /requerimientos/nuevo/, Cuando la página termina de cargar, Entonces todos los campos del formato ADM-F-22 aparecen vacíos (sin arrastrar un requerimiento anterior), la tabla de ítems muestra una sola fila en blanco, y el único valor precargado es el nombre del solicitante (tomado de la cuenta, y editable). La fecha de solicitud se asignará automáticamente al radicar.

Criterios de aceptación

Ningún campo (salvo el nombre) trae datos de un requerimiento previo.
La tabla de ítems arranca con una fila vacía.
La fecha de solicitud se registra con el día en curso al radicar.

Cubierto por: BorradorRequerimientoTests.test_sin_borrador_el_formulario_abre_en_blanco_y_sin_aviso, AutoriaRequerimientoTests.test_el_formulario_propone_el_nombre_de_la_cuenta, RequerimientoModelTests.test_fecha_solicitud_se_asigna_automaticamente.

CP-02 · Validación de campos obligatorios al radicar — HU-15

Dado un formulario con uno o más campos obligatorios sin diligenciar (solicitante, área, centro de costo, justificación, prioridad, fecha requerida o datos del ítem), Cuando el usuario pulsa «Radicar requerimiento», Entonces el sistema bloquea el envío, no crea ningún registro, resalta cada campo faltante con su mensaje y conserva lo ya diligenciado.

Criterios de aceptación

Un envío con cualquier campo obligatorio vacío se rechaza (status 200, 0 registros).
Un campo con solo espacios se considera vacío.
La validación aplica también a peticiones directas sin pasar por el navegador (fuente de verdad = servidor).
Los datos ya diligenciados se conservan tras el rechazo.

Cubierto por: ValidacionCamposObligatoriosTests (9 pruebas, incluida test_validacion_aplica_a_peticiones_directas_sin_navegador).

CP-03 · Guardado y reanudación de borradores — HU-18

Dado un requerimiento diligenciado a medias (con campos obligatorios aún faltantes), Cuando el usuario pulsa «Guardar borrador» y más tarde reabre el formulario, Entonces el sistema recupera de la sesión lo escrito (encabezado e ítems), muestra el aviso de borrador retomado y ofrece continuar o descartar.

Criterios de aceptación

Guardar borrador NO exige los campos obligatorios ni crea un requerimiento.
Al reabrir, el encabezado y los ítems vuelven con lo diligenciado.
El borrador es privado de cada solicitante.
Un formulario totalmente en blanco no guarda borrador.

Cubierto por: BorradorRequerimientoTests (22 pruebas).

CP-04 · Radicación exitosa y consecutivo único — HU-16, HU-17

Dado un requerimiento con todos los campos obligatorios válidos y al menos un ítem completo, Cuando el usuario confirma la radicación, Entonces el encabezado y sus ítems se guardan en una sola transacción, se asigna un consecutivo único REQ-AAAA-NNNN, se descarta el borrador, se avisa por correo al área de compras y el navegador queda en la pantalla de confirmación (patrón Post/Redirect/Get), de modo que recargar no duplica el requerimiento.

Criterios de aceptación

El consecutivo sigue el formato REQ-AAAA-NNNN y es único.
Dos radicaciones simultáneas nunca reciben el mismo número (concurrencia).
Recargar la confirmación no genera un duplicado.
Se dispara el correo al área de compras tras confirmar la transacción.

Cubierto por: ConsecutivoRadicacionTests, ConsecutivoConcurrenciaTests, ConfirmacionRadicacionTests, NotificacionAreaComprasTests.

CP-05 · Comportamiento en móvil y escritorio

Dado un usuario que abre el sistema a distintos anchos de pantalla, Cuando recorre el formulario y la tabla de ítems, Entonces la maquetación se adapta sin desbordamiento horizontal: la tabla de ítems desplaza en su propio contenedor y los datos de perfil se ocultan en la barra superior para dejar sitio a la navegación.

Criterios de aceptación

Sin scroll horizontal de página a 375 px ni a 1280 px.
La etiqueta meta viewport está presente (sin ella no hay responsive).

Cubierto por: IdentidadVisualTests.test_declara_el_viewport (lo demás es inspección visual manual — ver protocolo de usabilidad del Sprint 3).

CP-06 · Descarte del borrador — HU-18

Dado un formulario con un borrador retomado, Cuando el usuario pulsa «Descartar», Entonces la sesión se limpia y el formulario se recarga en blanco, sin el aviso.

Criterios de aceptación

Tras descartar, la clave de borrador desaparece de la sesión.
El formulario reabre en blanco y sin aviso de borrador.

Cubierto por: BorradorRequerimientoTests.test_descartar_borrador_deja_el_formulario_en_blanco.

CP-07 · Página de inicio pública

Dado un visitante sin sesión, Cuando abre la raíz del sitio, Entonces ve la presentación del sistema y el acceso al ingreso; si ya tenía sesión, se le lleva directo a su pantalla de trabajo.

Criterios de aceptación

El anónimo ve la portada con la descripción de cada perfil.
El usuario con sesión es redirigido a su pantalla según perfil.

Cubierto por: PortadaTests (4 pruebas).

CP-08 · Ingreso y enrutamiento por perfil

Dado un usuario con cuenta, Cuando ingresa con sus credenciales, Entonces cae en la pantalla de su perfil: solicitante → formulario, analista → bandeja, administrador → panel admin; si había pedido una pantalla concreta, se le devuelve a ella.

Criterios de aceptación

Cada perfil aterriza en su pantalla correcta.
El parámetro next tiene prioridad sobre el destino por perfil.

Cubierto por: IngresoTests (8), PerfilesTests (4).

CP-09 · Aislamiento de información entre solicitantes

Dado dos solicitantes distintos con requerimientos radicados, Cuando cada uno consulta «Mis requerimientos» o intenta abrir la confirmación de un consecutivo ajeno, Entonces cada quien ve únicamente lo suyo; el área de compras ve todo.

Criterios de aceptación

Un solicitante no puede ver la confirmación de un consecutivo ajeno (el consecutivo es adivinable).
«Mis requerimientos» filtra por autor.
Analista y administrador ven todos los requerimientos.

Cubierto por: AutoriaRequerimientoTests (4), BandejaTests (5), AccesoSinSesionTests (2).