Appearance
Plan de Certificacion
Plan estructurado para validar que cada proceso funcional de PROXIMITI opera correctamente en el entorno de produccion de Ontime antes del go-live. Cada script de prueba referencia las capacidades de la Matriz Funcional y los flujos documentados en la seccion de Procesos.
1. Estrategia de Certificacion
1.1 Fases
| Fase | Objetivo | Duracion Estimada | Participantes |
|---|---|---|---|
| Preparacion | Entorno configurado, datos maestros cargados, accesos creados | 1-2 semanas | IT Ontime + Desarrollo |
| Pruebas Unitarias de Integracion | Validar cada integracion externa (Azure AD, ALINA, NOVA, proveedores) | 1 semana | IT Ontime + Desarrollo |
| Pruebas Funcionales por Proceso | Ejecutar scripts de prueba proceso por proceso, cubrir flujo feliz y flujo de error | 2-3 semanas | Operaciones + QA |
| Pruebas de Carga | Validar rendimiento con volumetria proyectada de produccion | 1 semana | IT Ontime + Desarrollo |
| Piloto Controlado | Operacion real con centros seleccionados; minimo 2 semanas sin incidencias criticas | 2-4 semanas | Operaciones + Centros piloto |
| Go-Live | Rollout completo a todos los centros | 1 semana | Todos los equipos |
1.2 Entornos
| Entorno | Proposito | Datos | Acceso |
|---|---|---|---|
| Desarrollo | Desarrollo continuo y pruebas unitarias | Datos semilla sinteticos | Solo equipo de desarrollo |
| Staging / Pre-produccion | Certificacion funcional y pruebas de carga | Copia anonimizada de datos reales | QA + Operaciones + IT |
| Produccion | Operacion real | Datos reales | Todos los usuarios autorizados |
1.3 Roles en la Certificacion
| Rol | Responsabilidad | Perfil |
|---|---|---|
| Analista de certificacion | Ejecuta scripts de prueba, documenta resultados, reporta incidencias | Equipo QA de Ontime |
| Operador piloto | Prueba flujos reales de recepcion y entrega en centro PUDO | Operador de centro seleccionado |
| Transportista piloto | Prueba app carrier en ruta real (handshake, multi-drop, recogida) | Conductor de Ontime |
| IT Ontime | Valida integraciones, configura infraestructura, monitoriza | Equipo de sistemas |
| Equipo de desarrollo | Soporte tecnico, correccion de bugs, despliegue de fixes | Equipo dev PROXIMITI |
2. Pre-requisitos de Certificacion
Checklist de lo que debe estar listo antes de empezar cualquier script de prueba. Todos los items deben estar en estado OK para iniciar la fase de pruebas funcionales.
| # | Prerequisito | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 1 | Azure AD configurado con app registrations para BFF, portal y apps moviles | IT Ontime | Login exitoso en portal web y ambas apps moviles | ☐ |
| 2 | Roles Azure AD creados: USER_PUDO, USER_CARRIER, USER_ADMIN, USER_CUSTOMER, USER_BILLING | IT Ontime | JWT contiene roles correctos en claim roles | ☐ |
| 3 | Claim center_code mapeado en Azure AD (extension attribute o claims mapping policy) | IT Ontime | JWT incluye center_code con valor correcto para operadores | ☐ |
| 4 | Base de datos PostgreSQL 16 desplegada y accesible | IT Ontime | GET /actuator/health retorna UP en los 8 servicios | ☐ |
| 5 | Esquema de BD inicializado (tablas tp_pprx_*) | IT Ontime | Admin panel > Schema Explorer muestra todas las tablas | ☐ |
| 6 | Datos maestros cargados: centros, usuarios, tarifas | Operaciones | Admin panel muestra centros activos y tarifas configuradas | ☐ |
| 7 | ALINA ERP endpoint accesible desde la red de produccion | IT Ontime | curl al endpoint retorna 200 | ☐ |
| 8 | NOVA Mulesoft endpoint accesible y configurado (email/SMS) | IT Ontime | Notificacion de prueba recibida por email o SMS | ☐ |
| 9 | Azure Blob Storage configurado con contenedores proximiti-pod y proximiti-photos | IT Ontime | Upload y download de imagen de prueba exitosos | ☐ |
| 10 | Azure Blob Storage — contenedor proximiti-documents para contratos | IT Ontime | Upload de PDF de prueba exitoso | ☐ |
| 11 | SSL/TLS configurado en todos los endpoints publicos | IT Ontime | HTTPS sin warnings en navegador; certificados validos | ☐ |
| 12 | PUDO Manager App instalada en dispositivos de prueba (Android + iOS) | IT Ontime | Login exitoso y dashboard visible | ☐ |
| 13 | Carrier App instalada en dispositivos de prueba (Android + iOS) | IT Ontime | Login exitoso y lista de pendientes visible | ☐ |
| 14 | Proveedores externos accesibles: Kanguro API + Hublocker API | IT Ontime | Sync de catalogo ejecuta sin error desde admin panel | ☐ |
| 15 | Secrets HMAC compartidos con Kanguro y Hublocker para webhooks | IT Ontime | Webhook de prueba con firma valida procesado correctamente | ☐ |
| 16 | Red, firewall y DNS configurados — todos los servicios se comunican | IT Ontime | Health check de BFF retorna todos los downstream UP | ☐ |
| 17 | Zipkin desplegado y accesible para trazabilidad distribuida | IT Ontime | Traza end-to-end visible en Zipkin UI | ☐ |
| 18 | Variables de entorno configuradas en orquestador (~50 variables) | IT Ontime | Ver Requisitos Tecnicos para lista completa | ☐ |
| 19 | Backup automatico de BD configurado y probado | IT Ontime | Restauracion exitosa desde backup de prueba | ☐ |
| 20 | Monitorizacion y alertas configuradas (health checks, metricas, logs) | IT Ontime | Dashboard de monitoreo operativo con alertas activas | ☐ |
3. Scripts de Prueba por Proceso
Cada script referencia las capacidades de la Matriz Funcional por su ID (e.g., BFF-01, SHPM-06). La columna OK/NOK debe rellenarse durante la ejecucion. Si un paso falla, documentar el motivo en la columna de observaciones.
3.1 Creacion de Expedicion (E2E)
Capacidades: BFF-01, BFF-02, BFF-17, BFF-18, SHPM-01, SHPM-02, CP-13, CP-40 Actores: Cliente (portal web) Prerequisitos: Usuario cliente autenticado en Azure AD, centros PUDO activos con capacidad, tarifas configuradas
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Acceder al portal como cliente (USER_CUSTOMER) | Dashboard de cliente visible con KPIs de expediciones activas (CP-38) | ||
| 2 | Clic en "Enviar Paquete" | Formulario de nueva expedicion con pasos guiados (CP-13) | ||
| 3 | Completar datos de remitente y direccion de origen | Validacion de campos obligatorios; opcion de seleccionar direccion guardada (CP-40) | ||
| 4 | Seleccionar centro PUDO destino via widget | Mapa muestra centros cercanos por codigo postal (BFF-17); detalle con horario y capacidad (BFF-18) | ||
| 5 | Completar datos del paquete: destinatario, peso, dimensiones | Estimacion de tarifa visible basada en peso (CP-35, BFF-51) | ||
| 6 | Revisar resumen y confirmar envio | Mensaje de exito; codigo de barras generado (BFF-01, SHPM-01) | ||
| 7 | Enviar la misma peticion con la misma clave de idempotencia | No se crea duplicado; retorna la expedicion existente (BFF-01) | ||
| 8 | Acceder a "Mis Expediciones" | Expedicion aparece en la lista con estado PENDIENTE (CP-39, BFF-40) | ||
| 9 | Verificar notificacion al destinatario | Email o SMS recibido via NOVA (NOTF-04) | ||
| 10 | Verificar etiqueta imprimible | Generar etiqueta HTML con codigo de barras, remitente y datos del centro (BFF-10, SHPM-21) |
Criterio de aceptacion: Todos los pasos OK. La expedicion existe en BD con estado PENDIENTE y la notificacion fue entregada.
3.2 Recepcion en Centro PUDO
Capacidades: BFF-04..BFF-08, SHPM-06, SHPM-07, CNTR-07, CNTR-08, PUDO-06..PUDO-08 Actores: Operador PUDO (app movil) Prerequisitos: Expedicion en estado PENDIENTE, operador logueado en PUDO Manager
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Abrir PUDO Manager, login con Azure AD | Dashboard con conteo de expediciones pendientes y capacidad (PUDO-04) | ||
| 2 | Tocar "Recibir" en acciones rapidas | Pantalla de escaneo de codigo de barras activa (PUDO-06) | ||
| 3 | Escanear codigo de barras del paquete con camara | Paquete identificado; datos del remitente y destinatario mostrados | ||
| 4 | Verificar que hay capacidad disponible | Indicador de capacidad muestra espacio libre (PUDO-08); si lleno, muestra error amigable | ||
| 5 | Confirmar recepcion | Estado cambia a RECEPCIONADO (SHPM-07); capacidad decrementa en 1 (CNTR-08) | ||
| 6 | Verificar capacidad actualizada en dashboard | Espacios libres decrementados; indicador visual actualizado (PUDO-14) | ||
| 7 | Verificar en portal web como admin | Expedicion muestra RECEPCIONADO en timeline con timestamp (CP-09, CP-10) | ||
| 8 | Intentar recepcionar el mismo paquete de nuevo | Error: paquete ya recepcionado; no cambia de estado |
Criterio de aceptacion: Estado RECEPCIONADO confirmado en ambas interfaces. Capacidad del centro correctamente decrementada.
3.3 Entrega al Destinatario (con POD)
Capacidades: BFF-11..BFF-13, SHPM-08, SHPM-18..SHPM-20, PUDO-09..PUDO-11, CP-12 Actores: Operador PUDO + Destinatario Prerequisitos: Expedicion en estado RECEPCIONADO
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | En PUDO Manager, tocar "Entregar" | Pantalla de entrega con escaneo de codigo de barras | ||
| 2 | Escanear codigo de barras del paquete | Paquete identificado; datos mostrados para verificar destinatario | ||
| 3 | Solicitar firma del destinatario en pantalla | Canvas de firma aparece; el destinatario firma con el dedo (PUDO-09) | ||
| 4 | Capturar firma | Firma almacenada localmente, lista para subida | ||
| 5 | Tomar foto de evidencia del paquete entregado | Camara activa; foto capturada (PUDO-09) | ||
| 6 | Registrar documento de identidad: tipo (DNI/NIE/Pasaporte) + ultimos 4 digitos | Datos de identificacion guardados (PUDO-09) | ||
| 7 | Confirmar entrega | Imagenes POD subidas a Azure Blob via URL presignada (SHPM-18, PUDO-10); estado cambia a ENTREGADO (SHPM-08, PUDO-11) | ||
| 8 | Verificar POD en portal web | Firma y foto de evidencia visibles en detalle de expedicion via streaming proxy (CP-12, BFF-13) | ||
| 9 | Verificar metadatos de POD via API | GET /pod retorna URLs de firma y evidencia (BFF-11, SHPM-19) | ||
| 10 | Verificar capacidad del centro | Espacios libres incrementados en 1 (CNTR-09) | ||
| 11 | Verificar notificacion de entrega | Remitente recibe confirmacion de entrega (NOTF-04) |
Criterio de aceptacion: Estado ENTREGADO confirmado. POD (firma + foto + ID) visible en portal. Capacidad correctamente incrementada.
3.4 Intercambio Transportista-Centro (Dual QR)
Capacidades: BFF-04..BFF-08, SHPM-12..SHPM-16, PUDO-07, PUDO-12, PUDO-13, CA-03..CA-05 Actores: Operador PUDO + Transportista Prerequisitos: Transportista logueado en Carrier App con paquetes asignados para entregar
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Transportista abre Carrier App, login con Azure AD | Lista de expediciones pendientes para entrega visible (CA-03) | ||
| 2 | Transportista inicia handshake en Carrier App | Token QR de sesion generado y codigo QR mostrado (SHPM-12, BFF-04) | ||
| 3 | Operador escanea QR del transportista con PUDO Manager | Sesion vinculada; operador ve lista de paquetes del transportista (SHPM-14, PUDO-07, BFF-06) | ||
| 4 | Operador confirma recepcion de los paquetes | Paquetes transicionan a RECEPCIONADO individualmente (SHPM-07) | ||
| 5 | Transportista ve confirmacion en Carrier App | Polling detecta sesion VALIDATED; lista actualizada (SHPM-13, BFF-05) | ||
| 6 | Verificar entrega en lote (3+ paquetes) | Todos los paquetes procesados; resultado individual por paquete (BFF-08, SHPM-16) | ||
| 7 | Verificar ambas apps muestran transaccion completada | Historial actualizado en ambas aplicaciones | ||
| 8 | Verificar timeout de sesion QR | Tras inactividad prolongada, la sesion expira; se requiere nuevo QR |
Criterio de aceptacion: Handshake completado sin errores. Todos los paquetes en estado RECEPCIONADO. Ambas apps reflejan la transaccion.
3.5 Caducidad y Recogida
Capacidades: EXPR-01..EXPR-05, SHPM-09..SHPM-11, SHPM-17, CA-05, BFF-09 Actores: Sistema (automatizado) + Transportista Prerequisitos: Expedicion en estado RECEPCIONADO con fecCaducidad vencida
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Esperar ejecucion del CronJob de caducidad (o forzar manualmente) | Expediciones vencidas transicionan a CADUCADO (EXPR-01, SHPM-09) | ||
| 2 | Verificar outbox transaccional | Registro creado en tabla outbox dentro de la misma transaccion (EXPR-04) | ||
| 3 | Verificar despacho a ALINA | Outbox record procesado; estado SENT o CONFIRMED (EXPR-02) | ||
| 4 | Verificar estado en portal web | Expedicion muestra CADUCADO en stepper con camino de caducidad de 6 pasos (CP-10) | ||
| 5 | Verificar cuenta regresiva | Indicador de retencion muestra "Caducado" en rojo (CP-11) | ||
| 6 | Transportista ve paquete en lista de recogidas pendientes | Carrier App muestra expediciones caducadas para recogida (SHPM-15, CA-05) | ||
| 7 | Transportista inicia recogida en Carrier App | Estado transiciona a LOCKED_FOR_RETRIEVAL (SHPM-10); capacidad incrementada (SHPM-17, CNTR-09) | ||
| 8 | Transportista confirma recogida del paquete | Estado transiciona a RECOGIDO | ||
| 9 | Sistema cierra ciclo | Estado final: RETIRADO (SHPM-11) | ||
| 10 | Verificar en portal | Timeline completo del camino de caducidad visible (6 pasos) |
Prueba adicional — DLQ:
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 11 | Simular fallo de ALINA (endpoint caido) | Outbox reintenta con backoff exponencial hasta 5 intentos (EXPR-05) | ||
| 12 | Verificar movimiento a DLQ | Registro movido a dead letter queue tras agotar reintentos | ||
| 13 | Admin re-dispara notificacion desde DLQ | Registro vuelve a PENDING con conteo de reintentos reseteado (EXPR-03) |
Criterio de aceptacion: Ciclo completo de caducidad verificado. ALINA notificada. DLQ funciona correctamente con reintentos.
3.6 Seguimiento de Expedicion
Capacidades: BFF-19, SHPM-05, CP-10, CP-41 Actores: Cliente, Administrador, Publico (sin autenticacion) Prerequisitos: Expedicion existente con historial de estados
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Acceder a "Seguir Paquete" en portal cliente | Formulario de busqueda por codigo de barras (CP-41) | ||
| 2 | Ingresar codigo de barras valido | TrackingStepper muestra timeline con estados completados en verde y pendientes en gris (CP-10) | ||
| 3 | Verificar camino feliz (3 pasos) | PENDIENTE → RECEPCIONADO → ENTREGADO con ETA bajo ENTREGADO | ||
| 4 | Verificar camino de caducidad (6 pasos) | PENDIENTE → RECEPCIONADO → CADUCADO → LOCKED → RECOGIDO → RETIRADO | ||
| 5 | Acceder via URL directa /track/{barcode} | Mismo resultado que busqueda manual (BFF-19) | ||
| 6 | Consultar sin autenticacion (tracking publico) | Datos basicos de tracking visibles sin token JWT (SHPM-05) | ||
| 7 | Ingresar codigo de barras inexistente | Mensaje de error claro: "Expedicion no encontrada" |
Criterio de aceptacion: Ambos caminos del stepper se visualizan correctamente. Tracking publico funciona sin autenticacion.
3.7 Administracion del Sistema
Capacidades: BFF-20..BFF-31, CP-23..CP-29, CP-33, CP-34 Actores: Administrador Prerequisitos: Login como admin (USER_ADMIN)
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Acceder a panel de admin | Dashboard admin con KPIs: totales, desglose por estado, actividad 24h (BFF-16, CP-05) | ||
| 2 | Tab Usuarios: listar usuarios | Tabla paginada con todos los usuarios (BFF-20, CP-23) | ||
| 3 | Tab Usuarios: editar rol y asignar centro | Rol y centro actualizados correctamente (BFF-22, CP-23) | ||
| 4 | Tab Centros: listar con filtro por proveedor y estado | Tabla con badges de estado y proveedor (BFF-23, CP-24) | ||
| 5 | Tab Centros: crear centro nuevo (5 tabs: Basico/Estado/Contacto/Horario/Tipo) | Centro creado con 201; aparece en lista (BFF-25) | ||
| 6 | Tab Centros: editar centro con control de concurrencia | Actualizacion exitosa con ETag correcto; 412 con ETag obsoleto (BFF-26) | ||
| 7 | Tab Centros: borrado logico de centro | Centro desactivado; no aparece en listas publicas (BFF-27) | ||
| 8 | Tab Datos Semilla: verificar estado | Conteos por tabla de dominio correctos (BFF-28) | ||
| 9 | Tab Salud del Sistema: verificar servicios | Todos los servicios retornan UP | ||
| 10 | Tab Schema Explorer: navegar ERD | Diagrama entidad-relacion interactivo con todas las tablas tp_pprx_* (CP-26) | ||
| 11 | Tab Schema: detalle de tabla | Columnas, PK, FK, CHECK, UNIQUE, indices visibles (CP-27) | ||
| 12 | Tab Schema: buscar tabla | Filtro resalta tabla en canvas (CP-28) | ||
| 13 | Tab API Docs: Swagger UI | Swagger funcional con agrupacion por tags (CP-33, CP-34) | ||
| 14 | Tab API Docs: autenticacion OAuth2 | Autenticar via OAuth2 y ejecutar endpoint de prueba (BFF-66) | ||
| 15 | Verificar guard de rol | Acceder a /admin como operador redirige a / (CP-04) |
Criterio de aceptacion: Todas las funciones de administracion operativas. CRUD de centros y usuarios funcional. Schema Explorer y Swagger accesibles.
3.8 Gestion de Tarifas
Capacidades: BFF-50..BFF-55, CP-35, CP-36, CP-44 Actores: Administrador + Cliente Prerequisitos: Tarifas reales de Ontime cargadas en el sistema
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Admin: listar todas las tarifas (incluyendo inactivas) | Lista completa con rangos de peso y precios (BFF-52, CP-36) | ||
| 2 | Admin: crear nueva tarifa con rangos de peso | Tarifa creada y visible en lista (BFF-53) | ||
| 3 | Admin: editar tarifa existente | Cambios persistidos correctamente (BFF-54) | ||
| 4 | Admin: eliminar tarifa | Tarifa eliminada; desaparece de la lista (BFF-55) | ||
| 5 | Cliente: ver tarifas activas | Solo tarifas activas visibles (BFF-50) | ||
| 6 | Cliente: estimar coste por peso | Calculo correcto basado en rangos (BFF-51, CP-35, CP-44) |
Criterio de aceptacion: CRUD de tarifas funcional. Calculadora de coste retorna valores correctos segun rangos configurados.
3.9 Incidencias y Soporte
Capacidades: BFF-45..BFF-49, ISSU-01..ISSU-07 Actores: Operador PUDO + Administrador Prerequisitos: Expedicion existente para vincular la incidencia
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Operador: crear incidencia vinculada a expedicion | Incidencia creada con tipo, severidad y referencia (BFF-47, ISSU-01) | ||
| 2 | Operador: ver detalle de incidencia | Trail de auditoria visible con timestamp de creacion (BFF-46, ISSU-02) | ||
| 3 | Admin: listar incidencias con filtros | Filtrado por estado, tipo, severidad y centro funcional (BFF-45, ISSU-03) | ||
| 4 | Admin: cambiar estado (abierta → en curso → resuelta → cerrada) | Transicion registrada en trail de auditoria (BFF-48, ISSU-04, ISSU-07) | ||
| 5 | Operador: escalar incidencia no resuelta | Severidad incrementada; registro en trail (BFF-49, ISSU-05) | ||
| 6 | Verificar chat de soporte | Token de sesion generado (stub en v2.0; produccion requiere proveedor real) (ISSU-06) |
Criterio de aceptacion: Ciclo completo de incidencia operativo. Trail de auditoria refleja todos los cambios. Escalado funciona correctamente.
3.10 Notificaciones
Capacidades: BFF-42..BFF-44, NOTF-01..NOTF-05, CP-21, CP-22 Actores: Operador PUDO + Sistema Prerequisitos: Notificaciones existentes en el sistema
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Verificar badge de campana en portal | Conteo de no leidas visible (CP-22, BFF-43, NOTF-02) | ||
| 2 | Acceder a pagina de notificaciones | Lista paginada filtrada por centro del operador (CP-21, BFF-42, NOTF-01) | ||
| 3 | Marcar notificacion como leida | Conteo de no leidas disminuye (BFF-44, NOTF-03) | ||
| 4 | Trigger de notificacion por evento (e.g., recepcion de paquete) | Notificacion creada en BD + envio via NOVA (NOTF-04, NOTF-05) | ||
| 5 | Verificar envio real via NOVA (produccion) | Email o SMS recibido por el destinatario |
Criterio de aceptacion: Notificaciones se crean por eventos. NOVA entrega mensajes. Badge y lista funcionan correctamente.
3.11 Integraciones Externas
Capacidades: BFF-32, BFF-33, ADPT-01..ADPT-06, CP-30..CP-32 Actores: IT Ontime + Administrador
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| Autenticacion | ||||
| 1 | Azure AD: login portal web | Redirect a Azure AD, tokens validos, roles correctos en JWT | ||
| 2 | Azure AD: login PUDO Manager (AppAuth flow) | Callback exitoso, token almacenado en secure storage | ||
| 3 | Azure AD: login Carrier App (AppAuth flow) | Callback exitoso, token almacenado en secure storage | ||
| 4 | Azure AD: refresco silencioso de token | Token renovado sin interaccion del usuario | ||
| 5 | Azure AD: token invalido rechazado | Respuesta 401 Unauthorized (BFF-64) | ||
| ERP — ALINA | ||||
| 6 | Trigger caducidad → outbox → ALINA | Outbox record creado → HTTP POST a ALINA → estado CONFIRMED (EXPR-02) | ||
| 7 | ALINA rechaza mensaje | Reintento con backoff exponencial; DLQ tras 5 intentos (EXPR-05) | ||
| Notificaciones — NOVA | ||||
| 8 | Trigger evento → llamada a NOVA | HTTP call a NOVA API → email/SMS recibido (NOTF-05) | ||
| 9 | NOVA no responde (timeout 500ms) | Accion principal no se bloquea; fire-and-forget (NOTF-05) | ||
| Proveedores | ||||
| 10 | Kanguro: sync de catalogo desde admin | Centros Kanguro visibles en admin panel (BFF-32, ADPT-01) | ||
| 11 | Hublocker: sync de catalogo desde admin | Lockers Hublocker visibles en admin panel (BFF-32, ADPT-01) | ||
| 12 | Kanguro: webhook con firma HMAC valida | Webhook procesado correctamente (ADPT-04) | ||
| 13 | Kanguro: webhook con firma HMAC invalida | Webhook rechazado (ADPT-04) | ||
| 14 | Hublocker: webhook con firma HMAC valida | Webhook procesado correctamente (ADPT-05) | ||
| Almacenamiento | ||||
| 15 | Upload POD (firma + foto) a Azure Blob | Imagenes subidas y visibles via streaming proxy (BFF-12, BFF-13) | ||
| 16 | Upload foto de perfil a Azure Blob | Foto visible en header del portal (BFF-56, BFF-57) | ||
| 17 | Eliminar foto de perfil | Foto eliminada; no recuperable (BFF-58) | ||
| 18 | Upload documento de contrato (PDF) | PDF subido a contenedor proximiti-documents (CNTR-06) |
Criterio de aceptacion: Todas las integraciones responden correctamente. Flujos de error (timeout, rechazo) manejados con gracia.
3.12 Modo Offline (Apps Moviles)
Capacidades: PUDO-17, PUDO-18, CA-06, CA-07 Actores: Operador PUDO + Transportista Prerequisitos: Dispositivo con apps instaladas y operativas
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Activar modo avion en dispositivo | Banner de "Sin conexion" visible en ambas apps | ||
| 2 | PUDO Manager: recepcionar paquete offline | Operacion almacenada en Hive local (PUDO-17) | ||
| 3 | Carrier App: registrar entrega offline | Operacion almacenada en cola offline (CA-06) | ||
| 4 | Desactivar modo avion | Banner de conectividad desaparece | ||
| 5 | Verificar sincronizacion automatica | Operaciones pendientes se sincronizan con el servidor (PUDO-18, CA-07) | ||
| 6 | Verificar consistencia de datos | Estados en servidor coinciden con las operaciones locales |
Criterio de aceptacion: Operaciones offline se almacenan correctamente y se sincronizan sin perdida de datos al restaurar conectividad.
3.13 Perfil y Foto de Usuario
Capacidades: BFF-34..BFF-39, BFF-56..BFF-58, USR-01..USR-15, CP-37, CP-42, CP-43 Actores: Operador PUDO + Cliente Prerequisitos: Usuarios autenticados
| Paso | Accion | Resultado Esperado | OK/NOK | Observaciones |
|---|---|---|---|---|
| 1 | Operador: ver pagina de perfil | Info personal, centro asignado, enlace a seguridad de Azure AD (CP-37) | ||
| 2 | Operador: subir foto de perfil | Foto visible en header y dropdown (BFF-56, BFF-57) | ||
| 3 | Operador: eliminar foto de perfil | Avatar vuelve a iniciales; foto no recuperable (BFF-58) | ||
| 4 | Cliente: ver y editar perfil | Nombre, telefono y datos actualizados (CP-43, BFF-34, BFF-35) | ||
| 5 | Cliente: CRUD de direcciones | Crear, editar y eliminar direccion (CP-42, BFF-36..BFF-39) | ||
| 6 | Primer login de usuario nuevo | Auto-provision crea registro en BD (BFF-60, USR-02, USR-11) |
Criterio de aceptacion: Perfiles visibles y editables. Foto de perfil funcional. Auto-provision en primer login.
4. Pruebas de Carga
Ejecutar con herramienta de carga (e.g., k6, JMeter, Gatling) contra el entorno de staging con datos representativos de produccion.
| Escenario | Descripcion | Metrica Objetivo | OK/NOK |
|---|---|---|---|
| Creacion masiva de expediciones | 1.000 expediciones creadas en 1 hora | < 500ms p95 por creacion | |
| Consulta concurrente de tracking | 100 consultas simultaneas al endpoint publico de tracking | < 200ms p95 por consulta | |
| Sincronizacion de proveedores | Catalogo de 500 centros desde Kanguro | < 30s sync completo | |
| Upload concurrente de POD | 50 uploads simultaneos (firma + foto, ~500KB cada uno) | < 2s p95 por upload | |
| Dashboard de admin con volumetria real | Dashboard con 10.000 expediciones en BD | < 1s carga completa | |
| Widget PUDO selector | 100 busquedas concurrentes por codigo postal | < 300ms p95 por busqueda | |
| Listado paginado de expediciones | 50 consultas concurrentes con filtros y paginacion | < 300ms p95 | |
| Login concurrente | 50 logins simultaneos via Azure AD | < 3s p95 por login completo | |
| Polling de sesion QR | 100 clientes polling cada 2s durante 5 minutos | < 100ms p95 por poll |
Criterio de aceptacion: Todas las metricas dentro de los objetivos. Sin errores 5xx bajo carga sostenida. Sin degradacion de tiempos de respuesta despues de 30 minutos.
5. Criterios Go / No-Go
5.1 Criterios Go (TODOS deben cumplirse)
| # | Criterio | Verificacion | Estado |
|---|---|---|---|
| 1 | Integraciones externas funcionales: Azure AD, ALINA, NOVA | Script 3.11 — todos los pasos OK | ☐ |
| 2 | Flujo E2E completo: creacion → recepcion → entrega → POD visible | Scripts 3.1 + 3.2 + 3.3 — todos OK | ☐ |
| 3 | Flujo de caducidad completo: CADUCADO → outbox → ALINA → recogida | Script 3.5 — todos los pasos OK | ☐ |
| 4 | Handshake dual-QR operativo entre ambas apps | Script 3.4 — todos OK | ☐ |
| 5 | Apps moviles instaladas y funcionales en dispositivos objetivo (Android + iOS) | Login + escaneo + POD en ambas apps | ☐ |
| 6 | Datos maestros cargados y verificados | Admin panel muestra centros, usuarios, tarifas correctos | ☐ |
| 7 | Pruebas de carga superan metricas objetivo | Seccion 4 — todas las metricas dentro de objetivo | ☐ |
| 8 | Backup y recuperacion probados | Restauracion exitosa desde backup con datos intactos | ☐ |
| 9 | Monitorizacion y alertas configuradas | Dashboard de monitoreo operativo; alertas para servicios caidos | ☐ |
| 10 | Equipo de soporte nivel 1 formado | Al menos 2 personas capacitadas en operacion PROXIMITI | ☐ |
| 11 | Documentacion de operacion entregada | Guias de operador PUDO y transportista disponibles y revisadas | ☐ |
| 12 | Piloto controlado exitoso (minimo 2 semanas) | Sin incidencias criticas durante piloto | ☐ |
| 13 | Modo offline probado y funcional | Script 3.12 — sincronizacion sin perdida de datos | ☐ |
| 14 | Tarifas reales configuradas y validadas | Tarifas de Ontime sustituyen las ilustrativas | ☐ |
| 15 | SSL/TLS activo en todos los endpoints publicos | Certificados validos; HTTPS sin warnings | ☐ |
5.2 Criterios No-Go (CUALQUIERA bloquea el go-live)
| # | Criterio | Impacto | Mitigacion |
|---|---|---|---|
| 1 | Fallo en autenticacion Azure AD | Ningun usuario puede acceder al sistema | Verificar app registrations, roles, claims |
| 2 | ALINA no responde o rechaza mensajes | Paquetes caducados no se reportan; no se recogen | Verificar endpoint, credenciales, formato de mensaje |
| 3 | Perdida de datos POD (firma/foto) | Sin prueba de entrega — implicaciones legales | Verificar Azure Blob, presigned URLs, buckets |
| 4 | Error en calculo o configuracion de tarifas | Facturacion incorrecta a clientes | Verificar rangos de peso y precios con Operaciones |
| 5 | Centro PUDO no recibe actualizaciones de capacidad | Sobre-asignacion de paquetes; centro desbordado | Verificar ETag/concurrencia en servicio de centros |
| 6 | Apps moviles crashean en dispositivos objetivo | Operadores y transportistas no pueden trabajar | Probar en dispositivos reales representativos |
| 7 | Modo offline pierde operaciones al sincronizar | Paquetes recepcionados o entregados sin registrar | Verificar cola Hive y reconciliacion |
| 8 | Notificaciones NOVA no se entregan | Destinatarios no saben que su paquete esta listo | Verificar canales email/SMS y configuracion NOVA |
6. Gestion de Incidencias durante Certificacion
6.1 Clasificacion de Severidad
| Severidad | Definicion | Tiempo de Respuesta | Ejemplo |
|---|---|---|---|
| Critica (P1) | Bloquea un proceso completo; no existe workaround | 4 horas | Login no funciona, POD no se guarda, expedicion no se crea |
| Alta (P2) | Funcionalidad degradada pero con workaround disponible | 24 horas | Notificaciones no llegan, sync de proveedor falla, dashboard lento |
| Media (P3) | Error en flujo secundario; no afecta operacion principal | 48 horas | Filtro de busqueda no funciona, tooltip FK no aparece |
| Baja (P4) | Cosmetico, mejora o texto | Siguiente sprint | Texto mal alineado, icono incorrecto, color fuera de paleta |
6.2 Proceso de Gestion
- Registro: El analista de certificacion documenta la incidencia con severidad, script afectado y paso fallido
- Triaje: El equipo de desarrollo confirma la severidad y asigna responsable (maximo 2 horas para P1)
- Correccion: El equipo de desarrollo implementa el fix y despliega en staging
- Re-certificacion: El analista re-ejecuta el script afectado desde el paso fallido
- Cierre: El analista confirma la correccion y marca la incidencia como resuelta
6.3 Criterio de Parada
Si se acumulan 3 o mas incidencias P1 abiertas simultaneamente, se detiene la certificacion hasta resolver todas las P1. El equipo de desarrollo tiene prioridad absoluta sobre la certificacion durante este periodo.
7. Checklist Final Pre-Go-Live
Verificacion final el dia anterior al go-live. Cada item debe estar firmado por el responsable.
7.1 Infraestructura
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 1 | Todos los servicios (8) desplegados y saludables | IT Ontime | GET /actuator/health retorna UP en cada servicio | ☐ |
| 2 | PostgreSQL 16 operativo con replicas (si aplica) | IT Ontime | Conexion desde todos los servicios confirmada | ☐ |
| 3 | Azure Blob Storage con 3 contenedores configurados | IT Ontime | Upload/download de prueba en pod, photos, documents | ☐ |
| 4 | SSL/TLS activo en todos los endpoints publicos | IT Ontime | curl -I https://... muestra certificado valido | ☐ |
| 5 | DNS configurado para dominio de produccion | IT Ontime | Resolucion DNS correcta desde red interna y externa | ☐ |
| 6 | Load balancer configurado (si aplica) | IT Ontime | Trafico distribuido correctamente; health checks activos | ☐ |
7.2 Seguridad
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 7 | Azure AD operativo con todos los roles y claims | IT Ontime | Login exitoso con cada rol; JWT contiene claims correctos | ☐ |
| 8 | Secrets gestionados via vault o variables de entorno seguras | IT Ontime | Ningun secret en texto plano en configuracion | ☐ |
| 9 | Rate limiting activo (60/min IP, 120/min sujeto) | IT Ontime | Rafaga de peticiones retorna 429 (BFF-63) | ☐ |
| 10 | CORS configurado para dominios de produccion | IT Ontime | Peticiones cross-origin bloqueadas desde dominios no autorizados | ☐ |
| 11 | Webhooks protegidos con firma HMAC | IT Ontime | Webhook sin firma valida rechazado | ☐ |
7.3 Datos
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 12 | Datos maestros de centros PUDO cargados y verificados | Operaciones | Admin panel muestra todos los centros activos | ☐ |
| 13 | Usuarios creados con roles y centros asignados | Operaciones | Cada operador puede loguearse y ve su centro | ☐ |
| 14 | Tarifas reales de Ontime configuradas | Operaciones | Calculadora retorna precios correctos | ☐ |
| 15 | Backup automatico programado y probado | IT Ontime | Restauracion exitosa desde ultimo backup | ☐ |
7.4 Integraciones
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 16 | ALINA: endpoint de produccion accesible y probado | IT Ontime | Mensaje de prueba enviado y CONFIRMED | ☐ |
| 17 | NOVA: endpoint de produccion accesible y probado | IT Ontime | Email/SMS de prueba recibido | ☐ |
| 18 | Kanguro: API de produccion accesible; sync exitoso | IT Ontime | Centros Kanguro visibles en admin | ☐ |
| 19 | Hublocker: API de produccion accesible; sync exitoso | IT Ontime | Lockers Hublocker visibles en admin | ☐ |
| 20 | Zipkin: trazabilidad end-to-end operativa | IT Ontime | Traza completa visible para peticion de prueba | ☐ |
7.5 Aplicaciones
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 21 | Portal web desplegado y accesible via HTTPS | IT Ontime | Login exitoso; dashboard visible | ☐ |
| 22 | PUDO Manager publicada en App Store / Google Play (o MDM) | IT Ontime | Instalacion y login exitosos en dispositivos operadores | ☐ |
| 23 | Carrier App publicada en App Store / Google Play (o MDM) | IT Ontime | Instalacion y login exitosos en dispositivos transportistas | ☐ |
| 24 | Widget PUDO Selector integrado en sitio de Ontime (si aplica) | IT Ontime | Widget muestra centros cercanos por codigo postal | ☐ |
7.6 Formacion y Soporte
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 25 | Guia de operador PUDO entregada y revisada | Operaciones | Operadores piloto confirman comprension | ☐ |
| 26 | Guia de transportista entregada y revisada | Operaciones | Transportistas piloto confirman comprension | ☐ |
| 27 | Equipo soporte nivel 1 formado (minimo 2 personas) | Operaciones | Capacitacion completada; escalado definido | ☐ |
| 28 | Runbook de operacion entregado a IT | Desarrollo | Procedimientos de reinicio, rollback, escalado | ☐ |
| 29 | Contactos de escalado definidos (nivel 1 → nivel 2 → desarrollo) | Operaciones | Lista de contactos documentada y distribuida | ☐ |
7.7 Monitorizacion
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 30 | Health checks configurados para los 8 servicios | IT Ontime | Alerta automatica si un servicio cae | ☐ |
| 31 | Dashboard de metricas operativo (latencia, errores, throughput) | IT Ontime | Metricas visibles en tiempo real | ☐ |
| 32 | Alertas configuradas: servicio caido, errores 5xx, latencia alta | IT Ontime | Alerta de prueba recibida por el equipo | ☐ |
| 33 | Logs centralizados y accesibles | IT Ontime | Busqueda por X-Correlation-Id retorna trazas completas | ☐ |
7.8 Contingencia
| # | Item | Responsable | Verificacion | Estado |
|---|---|---|---|---|
| 34 | Plan de rollback documentado | Desarrollo | Procedimiento probado para revertir a estado anterior | ☐ |
| 35 | Punto de restauracion de BD creado | IT Ontime | Snapshot de BD tomado justo antes del go-live | ☐ |
| 36 | Comunicacion de go-live preparada (usuarios, stakeholders) | Operaciones | Email/comunicado redactado y aprobado | ☐ |
Apendice: Trazabilidad Matriz → Scripts
Referencia rapida para localizar en que script se certifica cada grupo de capacidades.
| Grupo de Capacidades | Script de Prueba |
|---|---|
| BFF-01..BFF-10 (Proxy expediciones) | 3.1, 3.2, 3.4 |
| BFF-11..BFF-13 (POD) | 3.3 |
| BFF-14..BFF-18 (Centros, Widget) | 3.1, 3.7 |
| BFF-19 (Tracking publico) | 3.6 |
| BFF-20..BFF-31 (Admin) | 3.7 |
| BFF-32..BFF-33 (Proveedores) | 3.11 |
| BFF-34..BFF-41 (Cliente) | 3.1, 3.13 |
| BFF-42..BFF-44 (Notificaciones) | 3.10 |
| BFF-45..BFF-49 (Incidencias) | 3.9 |
| BFF-50..BFF-55 (Tarifas) | 3.8 |
| BFF-56..BFF-58 (Foto perfil) | 3.13 |
| BFF-59..BFF-68 (Transversales) | 3.11, 3.7 |
| CNTR-01..CNTR-15 (Centros) | 3.2, 3.3, 3.5, 3.7 |
| SHPM-01..SHPM-25 (Expediciones) | 3.1, 3.2, 3.3, 3.4, 3.5, 3.6 |
| USR-01..USR-15 (Usuarios) | 3.7, 3.13 |
| NOTF-01..NOTF-05 (Notificaciones) | 3.10 |
| EXPR-01..EXPR-05 (Caducidad) | 3.5 |
| ISSU-01..ISSU-07 (Incidencias) | 3.9 |
| ADPT-01..ADPT-06 (Adaptador) | 3.11 |
| CP-01..CP-49 (Portal cliente) | 3.1, 3.6, 3.7, 3.8, 3.9, 3.10, 3.13 |
| PUDO-01..PUDO-19 (PUDO Manager) | 3.2, 3.3, 3.4, 3.12 |
| CA-01..CA-10 (Carrier App) | 3.4, 3.5, 3.12 |