Manual de pruebas — ArcorTruck BackOffice Web (prototipo)

Este documento es la guía operativa para probar la aplicación actual frente al alcance definido en functional_analisys.html (misma carpeta). El manual de usuario en PDF (docs/manual/Manual_BackOffice Web_Truck_v2.pdf) sigue siendo la fuente formal de negocio; aquí sólo describimos cómo reproducir comportamientos en este repositorio.

Qué incluye esta versión (y qué no)

Glosario breve

Preparación del entorno

Desarrollo (API + SPA)

1. Base SQL Server accesible con la cadena de src/GoTruckBackoffice.Api/appsettings.json (p. ej. contenedor Docker en localhost,14333 según docker-compose.yml en la raíz del repo).
2. API: desde src/GoTruckBackoffice.Api ejecutar dotnet run. Al arrancar aplican migraciones y se garantiza el usuario sembrado admin.
3. Web: desde src/Web, npm install y npm run dev → normalmente http://localhost:5173. Las peticiones a /api se proxifican en vite.config.ts hacia http://127.0.0.1:5000.

Sólo Docker Compose

Desde la raíz del proyecto: docker compose up --build.

Autenticación y seguridad

Credencial de demo

Otros usuarios se pueden crear desde #/registro (clave mínima cuatro caracteres). Usuario repetido produce error de conflicto con mensaje explícito.

Comportamiento esperado · UC-01 y UC-02

• Sin sesión, cualquier vista interna redirige a #/login. Guarda la ruta solicitada para volver allí después del login (variable interna del navegador).
• Login fallido (usuario o contraseña incorrectos): API 401 con mensaje genérico «Credenciales inválidas.» (no indica cuál campo falló).
• Sesión expirada o token rechazado (401) en llamadas REST: el cliente borra el token y ofrece volver al login.

Pruebas API rápidas (Swagger)

Abrir http://localhost:5000/swagger (o el mismo host donde expongas la API).

1. POST /api/auth/login · cuerpo {"usuario":"admin","clave":"admin"} → 200 y campo token.
2. Pulsa Authorize, escheme Bearer, pega el JWT.
3. GET /api/auth/me → 200.
4. GET /api/dashboard/summary sin Bearer → 401.
5. GET /api/health → sin autenticación (uso típico: salud/containers).

Mapa rápido: pantallas y casos de uso

Las rutas asumen # al principio cuando la app está en el navegador.

Cómo validar cada flujo principal

Los pasos están pensados como lista de chequeo QA. Para cada ítem marca: “visto en UI”, “API OK si aplica”, “pendiente backlog” si el prototipo sólo muestra texto.

1. Sesión (UC-01, UC-02)

1. Abrir la SPA sin estar logueado.
2. Comprobar pantalla login: campos Usuario / Clave, tabulación usable, enlaces claros.
3. Ingresar admin / admin: debe mostrarse el shell (menú + cabecera) y llegar al inicio o a la última URL que pediste antes del login.
4. Ejecutar Logout: debe volver a #/login y las peticiones siguientes sin token deben fallar donde la API está protegida.

2. Pantalla principal (UC-03)

1. Tras iniciar sesión, ir a #/inicio.
2. Verificar Menú lateral con entradas alineadas a Reparto · Administración móvil · Reportes · Tableros · Mapas · Configuración (+ enlace opcional Datos demo).
3. Verificar que las tarjetas del centro abren rutas coherentes sin recarga duradera fuera del fragmento SPA.
4. Navegar por el mismo módulo desde menú lateral y desde atajo para comprobar coherencia de destino.

3. Administración móvil (UC-04, UC-05, UC-06)

1. Ir #/administracion-movil.
2. UC-04 · Generar todos: pulse y confirme que aparece texto de trabajo simulado (no hay servidor de colas en esta build).
3. UC-05 · Generar un repartidor: sin elegir persona → mensaje de validación simple; con repartidor → mensaje OK simulado.
4. UC-06 · checkbox Proceso único diario: marca opcional y repita generación → el texto de confirmación debe reflejar sí/no del flag para demostrar intención de negocio.

4. Bloque Reportes (UC-07 … UC-12)

Para #/reportes/* repetir el mismo ritual en cada página:

1. Leer texto de filtros respecto del análisis (repartidor, hoja, tipo, desde/hasta, canal si aplica).
2. Ejecutar el botón de demo de tabla/generación donde exista — valida navegabilidad de la UI, no datos de negocio reales.
3. Anote como pendiente oficial: ordenación servidor, selección persistente en URL, Export Excel/impresión (UC pide ambos en producción futura).

Rutas concretas: reparto-por-hoja, devoluciones-por-hoja, cobranzas-por-hoja, cobranzas-general, desempeno, estadistico-entrega.

5. Tablero (UC-13)

#/tableros/avance-reparto — tabla de muestra de columnas de avance (% visita, contadores simples). Búsqueda mock presente pero sin efecto garantizado hasta backlog.

6. Mapa (UC-14, UC-15)

#/mapas/reparto — revisar filtros listados conforme UC-14 y bloque grande marcador/map placeholder. UC-15 (tooltip al clic sobre punto) pendiente hasta integración con mapa JS y modelo de marca.

7. Configuración BackOffice — técnico (UC-16)

#/configuracion/backoffice — revise que existan placeholders de configuración aplicación externa / BD externa / key Maps conforme texto funcional.

Ningún secreto debe persistirse desde el navegador; el botón de guardado en prototipo queda deliberadamente deshabilitado o sin backend.

8. Smoke de integración #/datos-demo

1. Con JWT válido, la vista debe poblar KPIs/tablas mediante servicios EF contra SQL (repartidores, clientes, hojas).
2. Si falla red o SQL está caído, aparece mensaje legible según cliente HTTP.

Incidentes típicos al probar

Trazabilidad documental

• Este manual ↔ pasos ejecutables QA en código actual del repo.
• functional_analisys.html ↔ modelo de procesos UC-01…UC-16 y matriz menú ↔ UC.
• PDF oficial ↔ validación wording final frente a distribuidoras y EMSER cuando el prototipo migre a entregables productivos.

Última redacción unificada del manual operativo QA del prototipo; actualizar rutas puertos si el despliegue corporativo cambia.