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

Casos de Prueba — Sprint 2

Casos de prueba de las historias desarrolladas en el Sprint 2, en formato Dado/Cuando/Entonces, con la prueba automática que cubre cada uno.

Tabla de trazabilidad

CP	HU	Tipo	Prueba automática
CP-S2-01	HU-34	Escenario (plantilla)	`AvisoConfirmacionRadicacionTests` (5)
CP-S2-02	HU-29	Integración (vistas SQL)	`VistasAnaliticasTests` (5)
CP-S2-03	HU-22	Integración (vista + permisos)	`FichaRequerimientoTests` (7)
CP-S2-04	HU-21	Integración (vista + filtros GET)	`FiltrosBandejaTests` (16)
CP-S2-05	HU-21	Integración (ordenamiento)	`FiltrosBandejaTests` (16, mismas pruebas)
CP-S2-06	HU-13	Integración (formulario + transacción)	`ProveedoresSugeridosTests` (13)
CP-S2-07	HU-14	Unitaria (modelo) + integración (formulario)	`ProductosSustitutosTests` (9)
CP-S2-08	HU-11	Unitaria (reglas) + integración (formulario, descarga y permisos)	`ValidacionAdjuntosTests` (10), `RadicarConAdjuntosTests` (8), `DescargaAdjuntoTests` (12), `ReglasAdjuntosBordesTests` (3), `EsquemaAdjuntoTests` (3)
CP-S2-09	HU-12	Integración (plantilla + formulario) + manual en móvil	`FotoDesdeMovilTests` (3)
CP-S2-10	HU-23	Unitaria (máquina de estados) + integración (vista, listados)	`TransicionesEstadoTests` (8), `CambiarEstadoVistaTests` (10), `EstadoEnListadosTests` (4), `EsquemaEstadoTests` (6)
CP-S2-11	HU-24	Unitaria (reglas) + integración (devolución, corrección y correo)	`DevolucionModeloTests` (8), `DevolverVistaTests` (9), `CorregirRequerimientoTests` (16), `NotificacionReenvioTests` (1), `FichaIdsUnicosTests` (1)

CP-S2-01 · Aviso de confirmación antes de enviar — HU-34

Dado un solicitante con el formulario de radicación diligenciado y válido, Cuando pulsa «Radicar requerimiento», Entonces no se envía de inmediato: aparece un aviso que resume solicitante, prioridad, fecha requerida y número de ítems, y solo al pulsar «Confirmar y radicar» se crea el requerimiento. Si pulsa «Revisar de nuevo», vuelve al formulario sin radicar.

Flujo alternativo: si faltan campos obligatorios, la validación de HU-15 frena antes del aviso. «Guardar borrador» no pasa por el aviso.

Criterios de aceptación

El formulario incluye el modal de confirmación con su resumen.
Una radicación confirmada (POST válido) crea el requerimiento.
Un envío inválido no crea nada.
Guardar borrador omite el aviso.

Cubierto por: AvisoConfirmacionRadicacionTests (5 pruebas).

CP-S2-02 · Vistas analíticas de solo lectura — HU-29

Dado requerimientos con sus ítems radicados, Cuando se consultan las vistas analitica_requerimientos y analitica_items, Entonces devuelven los datos desnormalizados (área, centro de costo, prioridad, fechas, año/mes, conteo de ítems y total estimado) listos para el tablero, sin exponer las tablas transaccionales.

Flujo alternativo: un requerimiento sin ítems reporta 0 ítems y total 0. Intentar escribir a través de la vista está prohibido.

Criterios de aceptación

La vista de requerimientos trae área, prioridad, fechas y total.
El rol de BD de solo lectura no puede insertar/actualizar/eliminar.
Power BI Desktop se conecta y carga sin transformaciones manuales.
El diccionario de campos está documentado en la Wiki.

Cubierto por: VistasAnaliticasTests (5 pruebas).

CP-S2-03 · Ficha completa del requerimiento — HU-22

Dado un analista de compras autenticado, Cuando abre la ficha de un requerimiento desde la bandeja, Entonces ve el encabezado completo, quién lo radicó, la justificación, los ítems con sus especificaciones y marcas, los precios y el total estimado.

Flujo alternativo: un solicitante que intenta abrir la ficha recibe 403; un consecutivo inexistente devuelve 404; sin sesión se redirige al ingreso.

Criterios de aceptación

El analista y el administrador ven la ficha completa.
Se muestran ítems, especificaciones, marcas y total.
Un solicitante no accede a la ficha de gestión (403).
Consecutivo inexistente → 404.
Las fotografías y documentos adjuntos, con miniatura para las fotos (integrado con HU-11; ver CP-S2-08).

Cubierto por: FichaRequerimientoTests (7 pruebas).

CP-S2-04 · Filtrar la bandeja de compras — HU-21

Dado un analista de compras autenticado con requerimientos radicados de varias áreas, prioridades y fechas, Cuando elige un área, una prioridad o un rango de fechas de radicación y pulsa «Aplicar», Entonces la bandeja muestra solo los requerimientos que cumplen todos los criterios elegidos, indica cuántos resultados hay y conserva los filtros al cambiar de página.

Flujo alternativo: si ningún requerimiento coincide, se muestra un aviso en lugar de la tabla vacía. Un valor inválido en la URL (un área que no existe, una fecha mal escrita, un rango con «desde» posterior a «hasta») se informa y ese criterio no se aplica, sin vaciar ni romper la bandeja. Un solicitante no puede entrar a la bandeja (403).

Criterios de aceptación

Filtra por área, por prioridad y por rango de fechas de radicación.
Los filtros se combinan entre sí.
Los filtros viajan en la URL: la vista filtrada se puede recargar, compartir y paginar.
Un parámetro inválido no rompe la bandeja.
«Limpiar» vuelve a la bandeja completa.
Filtro por estado (integrado con HU-23; ver CP-S2-10).

Cubierto por: FiltrosBandejaTests — happy: test_filtra_por_area, test_filtra_por_prioridad, test_filtra_por_rango_de_fechas_de_radicacion, test_los_filtros_se_combinan, test_la_paginacion_conserva_los_filtros; alterno: test_sin_coincidencias_muestra_un_aviso_y_no_falla, test_un_valor_invalido_se_informa_y_no_vacia_la_bandeja, test_un_rango_invertido_se_rechaza_y_no_se_aplica, test_un_solicitante_no_puede_filtrar_la_bandeja.

CP-S2-05 · Ordenar la bandeja de compras — HU-21

Dado un analista con la bandeja abierta, Cuando elige «Ordenar por» prioridad, fecha requerida o fecha de radicación, Entonces la bandeja se reordena: por prioridad (Alta primero, y a igual prioridad la fecha requerida más próxima), por la fecha requerida más próxima, o por fecha de radicación ascendente o descendente.

Flujo alternativo: sin orden elegido, o con un orden desconocido en la URL, se usa el orden por defecto: de lo más reciente a lo más antiguo.

Cubierto por: FiltrosBandejaTests — happy: test_ordena_por_prioridad_con_alta_primero, test_ordena_por_la_fecha_requerida_mas_proxima, test_ordena_de_lo_mas_antiguo_a_lo_mas_reciente; alterno: test_un_orden_desconocido_cae_en_el_orden_por_defecto.

CP-S2-06 · Sugerir hasta tres proveedores — HU-13

Dado un solicitante diligenciando el formulario de radicación, Cuando escribe el nombre y el teléfono de uno, dos o tres proveedores y radica, Entonces los proveedores quedan guardados con el requerimiento, en el orden en que los escribió, y el área de compras los ve en la ficha (con el teléfono como enlace para llamar) y en el correo de aviso.

Flujo alternativo: sugerir proveedores es opcional; radicar sin ninguno funciona. Una fila con nombre y sin teléfono, o con teléfono y sin nombre, o con un teléfono inválido (letras, menos de 7 o más de 15 dígitos), bloquea la radicación, marca la fila y conserva todo lo diligenciado. No se aceptan más de tres.

Criterios de aceptación

El formulario ofrece tres filas: nombre o razón social, teléfono y observaciones.
Texto libre: no hay maestro de proveedores (acuerdo n.º 3 con el cliente).
Una fila empezada exige nombre y teléfono válido.
Se guardan en la misma transacción que el requerimiento.
Se muestran en la ficha de compras y en el correo de aviso.
El borrador (HU-18) también los conserva.

Cubierto por: ProveedoresSugeridosTests — happy: test_radicar_guarda_los_proveedores_con_su_telefono, test_sugerir_proveedores_es_opcional, test_la_ficha_de_compras_muestra_los_proveedores, test_el_correo_a_compras_incluye_los_proveedores, test_el_borrador_conserva_los_proveedores; alterno: test_un_proveedor_sin_telefono_bloquea_la_radicacion, test_un_telefono_sin_nombre_bloquea_la_radicacion, test_un_telefono_con_letras_o_muy_corto_es_invalido, test_no_se_aceptan_mas_de_tres_proveedores.

CP-S2-07 · Indicar productos o servicios sustitutos — HU-14

Dado un solicitante diligenciando el formulario de radicación, Cuando marca que sí existen productos o servicios sustitutos, escribe cuáles y radica, Entonces el requerimiento queda con la respuesta y la descripción, y el área de compras las ve en la ficha y en el correo de aviso.

Flujo alternativo: por defecto la respuesta es «no». Si marca «sí» y deja la descripción vacía (o solo con espacios), la radicación se bloquea con un mensaje que pide escribir cuáles. Si responde «no», lo que haya escrito en la descripción se descarta.

Criterios de aceptación

Pregunta de sí o no; la descripción aparece solo si responde que sí.
«Sí» sin descripción no se puede radicar (lo valida el servidor y el modelo).
Se muestra en la ficha de compras y en el correo de aviso.
El borrador (HU-18) conserva la respuesta.

Cubierto por: ProductosSustitutosTests — happy: test_radicar_con_sustitutos_guarda_cuales, test_la_ficha_y_el_correo_muestran_los_sustitutos, test_el_borrador_conserva_la_respuesta; alterno: test_marcar_que_hay_sustitutos_sin_decir_cuales_bloquea_la_radicacion, test_si_responde_que_no_se_descarta_lo_escrito, test_el_modelo_tambien_exige_la_descripcion.

CP-S2-08 · Adjuntar fotografías y documentos de soporte — HU-11

Dado un solicitante diligenciando el formulario de radicación, Cuando adjunta una foto del artículo y la ficha técnica en PDF y radica, Entonces el requerimiento queda con sus dos adjuntos, la confirmación los lista, y el área de compras los ve en la ficha: la foto como miniatura y el PDF rotulado con su extensión. Cada adjunto se abre o se descarga con su nombre original.

Flujo alternativo:

Un tipo no admitido (por ejemplo .exe) o un archivo vacío no se radica.
Un archivo cuyo contenido no corresponde a su extensión —un ejecutable renombrado a .pdf, una página web renombrada a .jpg— no se radica.
Más de 10 archivos, o uno de más de 10 MB, no se radica.
Si fallan varios archivos, se informan todos de una vez y por nombre.
Si el encabezado tiene errores, se avisa que hay que volver a elegir los archivos: el navegador no los conserva.
Otro solicitante no puede ver el adjunto (responde 404, no 403); un usuario sin sesión es enviado al ingreso.

Criterios de aceptación

Se aceptan fotos (JPG, PNG, WEBP, HEIC) y documentos (PDF, Word, Excel).
Hasta 10 archivos de 10 MB cada uno; son opcionales.
Se valida la firma del archivo, no solo la extensión.
Los adjuntos solo se entregan por una vista que revisa permisos, nunca por una ruta pública.
Fotos y PDF se abren en el navegador; Word y Excel se descargan.
Borrar un adjunto, o el requerimiento, borra el archivo del disco.

Cubierto por: happy: test_radicar_con_una_foto_y_una_ficha_tecnica, test_acepta_cada_formato_con_su_firma_real, test_quien_radico_ve_su_adjunto, test_el_analista_ve_cualquier_adjunto, test_la_ficha_enlaza_la_descarga_protegida_y_no_el_archivo_directo; alterno: test_rechaza_un_ejecutable_disfrazado_de_pdf, test_rechaza_una_pagina_web_disfrazada_de_foto, test_un_archivo_invalido_no_deja_nada_radicado, test_pasarse_del_maximo_no_radica, test_otro_solicitante_no_lo_ve_ni_sabe_que_existe, test_borrar_el_requerimiento_borra_sus_archivos.

CP-S2-09 · Tomar la foto con la cámara del celular — HU-12

Dado un solicitante que abre el formulario desde un celular, Cuando pulsa «Tomar foto con la cámara», toma dos fotos y radica, Entonces las dos fotos quedan adjuntas al requerimiento, cada una con su propio nombre (foto-camara-1.jpg, foto-camara-2.jpg), junto con lo que haya elegido en el selector de archivos.

Flujo alternativo:

Una toma mal hecha se quita de la lista con «Quitar» y no viaja al servidor.
En un computador con mouse el botón no aparece: ahí la cámara no se abre.
Si el navegador no permite acumular fotos, la cámara guarda una sola.

Criterios de aceptación

El botón abre la cámara trasera (capture="environment").
Las fotos se acumulan en vez de reemplazarse.
Las fotos de la cámara pasan por las mismas reglas de HU-11 en el servidor.
El aviso de confirmación (HU-34) las cuenta en el resumen.

Cubierto por: happy: test_ofrece_abrir_la_camara_trasera, test_las_fotos_de_la_camara_se_suman_a_lo_elegido_en_el_selector; alterno: test_el_selector_de_camara_no_se_envia_por_si_mismo.

Ejecución manual: emulando un celular (375 px, pantalla táctil) se tomaron dos fotos, se quitó una y se radicó: el requerimiento quedó con la foto conservada. En escritorio se verificó que el botón no aparece.

CP-S2-10 · Cambiar el estado del requerimiento — HU-23

Dado un analista de compras con la ficha de un requerimiento radicado, Cuando lo pasa a «En revisión» con una observación, luego a «En cotización» y luego a «Cerrado», Entonces cada cambio queda en la bitácora con quién, cuándo y por qué; el estado se ve en la ficha, en la bandeja y en «mis requerimientos» del solicitante; y la bandeja se puede filtrar por estado.

Flujo alternativo:

No se pueden saltar pasos: de «Radicado» no se pasa directo a «Cerrado».
De «En cotización» se puede volver a «En revisión».
«Cerrado» es definitivo: la ficha ya no ofrece cambios.
Si dos analistas tienen la ficha abierta y actúan a la vez, el segundo cambio se rechaza con un aviso en lugar de pisar al primero.
Un solicitante no puede cambiar estados (403); el cambio solo entra por POST.

Criterios de aceptación

Los cinco estados del prototipo: Radicado, En revisión, Devuelto, En cotización y Cerrado.
La ficha ofrece solo los estados a los que se puede pasar.
Una transición rechazada no modifica nada.
Filtro por estado en la bandeja; un estado inválido en la URL no la deja en blanco.

Cubierto por: happy: test_el_flujo_completo_revisar_cotizar_y_cerrar, test_cada_cambio_queda_en_la_bitacora_con_quien_y_por_que, test_el_analista_pasa_el_requerimiento_a_revision, test_la_bandeja_filtra_por_estado, test_el_solicitante_ve_en_que_va_lo_suyo; alterno: test_no_se_puede_saltar_pasos, test_una_transicion_rechazada_no_toca_nada, test_se_valida_contra_la_base_de_datos_y_no_contra_la_memoria, test_el_solicitante_no_puede_cambiar_estados, test_un_requerimiento_cerrado_ya_no_ofrece_cambios.

CP-S2-11 · Devolver con observaciones y reenviar corregido — HU-24

Dado un analista con la ficha de un requerimiento al que le falta información, Cuando lo devuelve escribiendo qué falta, Entonces el requerimiento pasa a «Devuelto», al solicitante le llega un correo con la observación y el enlace para corregir, y en «mis requerimientos» lo ve destacado como pendiente de su corrección.

Y cuando el solicitante abre la corrección, ajusta lo que le pidieron, agrega la foto que faltaba y reenvía, Entonces el requerimiento vuelve a «Radicado» con el mismo consecutivo, su mensaje queda en la bitácora y el área de compras recibe un aviso.

Flujo alternativo:

Sin observación, o con menos de 10 caracteres, no se devuelve, y se conserva lo que el analista ya había escrito.
Un requerimiento cerrado ya no se puede devolver.
Si la cuenta no tiene correo o el servidor de correo falla, la devolución queda hecha igual.
Solo el dueño corrige, y solo mientras está devuelto (si no, 404).
Si la corrección tiene errores, no se reenvía y nada cambia.
El máximo de 10 adjuntos cuenta lo que ya había, menos lo que se quita.

Criterios de aceptación

Observación obligatoria para devolver, visible para el solicitante.
La corrección viene precargada: encabezado, ítems, proveedores y sustitutos.
Se pueden editar, agregar y quitar ítems, con la numeración consecutiva.
Se pueden quitar adjuntos y sumar otros.
Al reenviar se conserva el consecutivo y se avisa a compras.

Cubierto por: happy: test_el_analista_devuelve_con_su_observacion, test_al_solicitante_le_llega_la_observacion_y_el_enlace_para_corregir, test_reenviar_guarda_las_correcciones_y_vuelve_a_radicado, test_compras_se_entera_de_que_volvio_corregido, test_se_puede_agregar_la_foto_que_faltaba_y_quitar_la_que_sobraba; alterno: test_sin_observacion_no_se_devuelve_y_se_conserva_lo_escrito, test_lo_cerrado_no_se_puede_devolver, test_si_el_servidor_de_correo_falla_la_devolucion_queda_hecha, test_un_requerimiento_ajeno_no_se_puede_corregir, test_con_errores_no_reenvia_ni_cambia_nada.

Defectos encontrados al ejecutar este caso y corregidos en la misma historia:

#	Defecto	Severidad	Corrección
1	Al editar un requerimiento, los ítems nuevos se numeraban desde 1 y chocaban con los existentes (error de integridad).	Alta	Los ítems existentes conservan su número; los nuevos van después del mayor. Prueba de regresión: `test_editar_solo_el_tercer_item_no_choca_ni_reordena`.
2	La fecha requerida aparecía vacía al corregir: el selector de fecha solo entiende AAAA-MM-DD y la fecha se pintaba como dd/mm/aaaa. Venía de HU-05 y no se notaba al radicar.	Alta	Formato fijo en el campo. Prueba de regresión: `test_la_fecha_requerida_llega_en_el_formato_del_selector`.
3	Dos campos de la ficha tenían el mismo id (`id_observacion`), así que la etiqueta de «devolver» apuntaba al cuadro equivocado.	Media	Prefijo propio en el formulario de devolución. Prueba de regresión: `test_cada_campo_de_observacion_tiene_su_propio_id`.