Estrategia de pruebas - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

🧪 Documento de estrategia de pruebas

1. Aplicación bajo pruebas

1.1. Nombre de la aplicación

Solventa

1.2. Versión

1.0 (ciclo de arquitectura y prototipos MISW4501-202614) — estrategia v3, Semana 5

1.3. Descripción

Solventa es una aseguradora digital (insurtech) fundada en 2026, concebida desde cero (arquitectura greenfield y nativa en la nube) sobre el ecosistema de Finanzas Abiertas (Open Finance) y Datos Abiertos (Open Data). Opera como aseguradora de nicho y como plataforma de distribución de seguros embebidos orientada a APIs (API-first), con sede en Bogotá y expansión planeada a México, Chile y Perú.

La plataforma cotiza, suscribe, emite pólizas y paga siniestros de bajo monto de forma casi instantánea, embebiendo la cobertura en el punto de necesidad del cliente (por ejemplo al comprar un tiquete, alquilar un carro o originar un crédito hipotecario). El producto se ofrece por cliente web (gestión completa y back-office), cliente móvil (autoservicio en movilidad) y API embebida (socios de distribución).

1.4. Funcionalidades core y componentes a probar

Las capacidades de negocio a evaluar se describen en el documento base (MISW4501-202614-Proyecto).

Con el fin de asegurar tanto la Verificación (es decir, que el producto esté construido correctamente) como la Validación (que la solución corresponda realmente a lo que el negocio necesita), las pruebas se alinean de forma directa con la arquitectura de microservicios de Solventa. A continuación, se detallan los componentes técnicos evaluados para cada capacidad de negocio:

  • Cotización y precio (rating):
    • Componentes a probar: ms-cotizacion / :MsCotización, :MotorRaiting, ms-catalogo, :AdaptadorOF y :CacheOF. Se verifica el cálculo síncrono de la prima y que la llamada a Open Finance sea actualización oportunista, no dependencia bloqueante. :Consentimiento es precondición de esa salida a Open Finance en el modelo de componentes; no se ejercita como variable de PD-01.
  • Suscripción (underwriting) y Perfilamiento:
    • Componentes a probar: ms-suscripcion, ms-perfilamiento / :MsPerfilamiento, :MotorRiesgo, :AdaptadorOD, :AdaptadorKYC y :CacheOD. Se verifica la decisión automatizada, el fan-out paralelo OF/OD y el perfilamiento de riesgo individualizado (ej. seguro de vida hipotecario).
  • Emisión y gestión de pólizas:
    • Componentes a probar: ms-polizas / :MsPolizas, ms-consentimiento y firma fuera del camino crítico (:BusEventos). Ciclo de vida completo; firma y notificación no entran en el presupuesto de aceptación → póliza.
  • Distribución y socios (embedded):
    • Componentes a probar: :ApiGateway (:APISocios, :BFFWeb, :BFFMovil), ms-socios y ms-identidad (emisor JWT; validación en el BFF). Verificación de integración API-first, RBAC y control de cuotas para canales de terceros.
  • Siniestros y paramétricos:
    • Componentes a probar: ms-siniestros / :MsSiniestros (comando de aviso y modelo de lectura CQRS: proyector, siniestros_w / siniestros_r, caché Redis), ms-parametrico / :MotorParametrico, :AdaptadorTelemetria y :TopicoTelemetria. Flujos asistidos, consulta de estado p95 ≤ 150 ms y absorción de eventos climáticos/vuelos.
  • Cobros, pagos y recaudo:
    • Componentes a probar: ms-pagos / :MsPagos, :AdaptadorPasarela y :ColaPagos. Verificación estricta de reglas de idempotencia y desembolsos.
  • Experiencia de Cliente (Canales):
    • Componentes a probar: Cliente web (AngularJS/TypeScript, MVVM) y cliente móvil (Android Kotlin / Jetpack Compose: Presentation → Domain → Data, Room + WorkManager) interactuando exclusivamente a través de la Capa de Borde (:BFFWeb, :BFFMovil).

Esas capacidades viven una sola vez en el backend (Python). Web y móvil no son productos distintos: son canales sobre el mismo núcleo. En el corte MVP, cada canal cubre únicamente las historias marcadas mvp en el backlog refinado de Semana 3; las capacidades post-mvp se conservan como alcance posterior.

Recorridos críticos y dónde se prueban:

Recorrido Núcleo (API / dominio) Cliente web (AngularJS / TypeScript) Cliente móvil (Android / Kotlin / Jetpack Compose) API embebida
1. Cotización embebida Sí Sí (HU-10) Sí (HU-11) Sí (canal principal del socio)
2. Suscripción y emisión Sí Sí (HU-19) Sí (HU-20) Sí (contrato embebido)
3. Siniestro asistido Sí Sí (aviso y back-office / peritos) Sí (aviso con evidencia nativa) No (salvo estado vía socio)
4. Siniestro paramétrico Sí Sí (trazabilidad, HU-37) Sí (aviso in-app y consulta, HU-35/HU-36) No
5. Perfilamiento vida hipotecario Sí Sí (HU-58) Sí (consulta de oferta, HU-57) Sí (originación en banco aliado)
6. Ciclo de vida de la póliza Sí Sí (comandos de operador, HU-59…HU-63) Sí (avisos, HU-64/HU-65) Parcial (reportes mediante adaptadores stub)

Solo web en el MVP (no se duplican en móvil): venta asistida, back-office de siniestros, evaluación/enrutamiento y reportes internos al regulador y reaseguradora mediante stub. El panel de socios, autoservicio, orquestador maestro y tableros son post-mvp.

Solo móvil en el MVP: captura de una foto, geoetiquetado, conservación de evidencia ante caída de red y avisos in-app. Biometría, billetera offline, asistencia en sitio, mapa y escaneo de documentos son post-mvp.

Los experimentos de arquitectura de la Sec. 3 ejercitan esos mismos componentes frente a las historias de arquitectura del backlog refinado. El corte actual prioriza latencia y escalabilidad (HA-01…HA-13); los experimentos de otros atributos se conservan para ejecución posterior:

Componente Experimentos
ms-cotizacion / :MotorRaiting, :CacheOF, :AdaptadorOF PR-01, PD-01, PM-01
ms-perfilamiento, :AdaptadorOF / :AdaptadorOD, :CacheOD PR-02
ms-suscripcion, ms-polizas, :ColaPagos PR-05
ms-siniestros (modelo de lectura CQRS) PR-04
ms-parametrico, :TopicoTelemetria PR-03
:ApiGateway / :APISocios, ms-socios, ms-identidad PS-01, PI-01
ms-consentimiento PS-02
:BFFMovil / cliente Kotlin (Room + WorkManager) PD-03
Cliente web (AngularJS / MVVM) / cliente móvil (Compose) PL-01

1.5. Diagrama de arquitectura

La fuente vigente es la Hoja de trabajo semana 5. Visión de arquitectura y Semana 4 se conservan como histórico.

Las tácticas y patrones que esos modelos materializan (y que los experimentos de la Sec. 3 deben evidenciar) están en Tácticas y patrones y en el diseño detallado de Semana 5 §2.

1.6. Diagrama de contexto

El diagrama de contexto vigente está en Semana 5 §1.1 (el de Visión de arquitectura es el histórico): canales (web, móvil, API embebida), actores por canal y sistemas externos (Open Finance, Open Data, KYC, pagos, firma, IoT, reaseguro).

1.7. Modelo de datos

Dos niveles, ambos vigentes:

1.8. Modelo de GUI

La presentación ya tiene modelo de capas; no hay mockups pixel a pixel.

  • Web: MVVM del portal sobre Angular. Las pruebas de GUI cubren las HU de canal de las olas 1–4 (venta y back-office).
  • Móvil: capas Android. Las pruebas de GUI cubren cotización, póliza, evidencia, avisos y oferta hipotecaria. Biometría, billetera offline, mapas, asistencia, escaneo, panel de socios y tableros quedan post-mvp.

2. Alcance de pruebas

Alcance del periodo de pruebas: unitarias, módulo e integrales (rúbrica Semana 2). Incluye estilo general, objetivos, duración, presupuesto, TNT, distribución de esfuerzo, alcance negativo, riesgos y criterios de salida.

2.0. Estilo general

Solventa adopta pruebas continuas (no testing al final de la iteración ni TDD estricto): cada historia se considera terminada solo cuando incluye sus pruebas unitarias, y la integración/contrato/E2E corre en cada corte semanal junto con el desarrollo funcional, no después de él. Esto es consistente con la Sec. 2.6 (pruebas de unidad no negociables, sin sleep() ni acoplamiento a la UI) y con el cronograma de la Sec. 2.2, donde unitarias, integración y E2E se solapan en las mismas semanas en vez de reservarse para el final del ciclo.

Justificación: el equipo son cuatro ingenieros de arquitectura y desarrollo (no un área QA separada), y el ciclo de 8 semanas no tiene margen para una fase de pruebas aislada al cierre — la calidad debe evidenciarse de forma incremental en cada entrega semanal (S1–S8, Sec. 2.2).

2.1. Objetivos

  • Verificar en aislamiento las reglas y cálculos del núcleo compartido (una sola vez en dominio/Python), y la lógica de presentación de cada canal (web AngularJS/TypeScript y móvil Android Kotlin / Jetpack Compose)
  • Conocer el funcionamiento de Solventa y detectar defectos en los recorridos críticos con pruebas exploratorias manuales en cada canal donde aplique el recorrido
  • Verificar el ensamblaje entre canales, núcleo comercial y terceros (con dobles de Open Finance, Open Data, KYC y pagos)
  • Validar extremo a extremo los seis recorridos: el núcleo siempre; web y móvil cuando el recorrido es de cliente; API embebida cuando es de socio
  • Diseñar y ejecutar escenarios de validación de datos (válidos e inválidos) sobre Cotización, Suscripción, Pólizas, Siniestros, Pagos e Identidad
  • Obtener evidencia de que la arquitectura sostiene las metas medibles de latencia y escalabilidad priorizadas (HA-01…HA-13) mediante PR-01 (HA-09/HA-10), PR-02, PR-03, PR-04, PR-05 y PD-01 (HA-01/HA-02/HA-07; pregunta 3 del enunciado)
  • Verificar en aceptación la conservación idempotente de evidencia móvil cuando cae la red (HU-25). La billetera offline y su sincronización (HU-51/HU-52, PD-03) quedan post-mvp
  • Diseñar, pero no usar para ordenar el corte LAT/ESC, las pruebas de privacy & security by design y aislamiento entre socios (PS-01, PS-02)
  • Confirmar con GUI que web y móvil comparten el núcleo pero no son la misma interfaz redimensionada: cobertura total vs subconjunto + nativo
  • Verificar contratos estables entre canales y núcleo (PI-01, aceptación de HU-88) y bajo acoplamiento del motor de rating (PM-01)
  • Verificar que los canales web y móvil resuelven textos, moneda y fecha por locale sin tocar el núcleo, en línea con el Objetivo 3 de expansión a México, Chile y Perú (PL-01)

2.2. Duración de la iteración de pruebas

Iteración alineada al documento de alcance (EDT) del ciclo de 8 semanas. Semana 2: estrategia inicial y diseño de experimentos (Sec. 3); Semanas 3–5: frameworks y ambientes, refinamiento y diseño final (rúbrica: propósito, respuesta esperada, tecnologías, interpretación y esfuerzo); Semanas 6–7: prototipos y ejecución; Semana 8: análisis.

Tarea S1 S2 S3 S4 S5 S6 S7 S8
Diseño de la estrategia de pruebas X X X X
Definición de framework de pruebas X
Diseño de experimentos de arquitectura (PR, PD, PS, PI, PM) X X X
Pruebas unitarias (núcleo compartido y canales) X X X
Pruebas exploratorias X X
Pruebas de integración y contrato (incl. PI-01) X X X X X
Pruebas E2E de recorridos críticos X X
Validación de datos X X
Ejecución de experimentos (rendimiento, resiliencia, seguridad) X X
Pruebas de GUI manuales (core en web y móvil + PD-03) X X
Análisis de resultados X X

2.3. Presupuesto de pruebas

El ciclo de planeación y arquitectura estima ~15 h/sem por integrante durante 8 semanas (visión de arquitectura). De ese cupo se destinan 8 h/sem a actividades de esta estrategia (64 h por persona; 256 h en total).

2.3.1. Recursos humanos

Recurso Rol en pruebas Valor/hora (COP) Horas Valor total (COP)
John Guerrero Ingeniero 1 — cotización embebida, API de socios, PR-01 70.769 64 4.529.216
Mauricio Rodriguez Ingeniero 2 — suscripción, perfilamiento, PR-02 / PR-05 / PS-02 70.769 64 4.529.216
Juan Acevedo Ingeniero 3 — siniestros paramétricos, PR-03 / PR-04 / PD-01 70.769 64 4.529.216
Martin Romero Ingeniero 4 — ciclo de vida, canal móvil, PD-03 / PS-01 / PI-01 / PM-01 70.769 64 4.529.216
Total 256 18.116.864

Fuente de tarifa de referencia: talent.com — ingeniero QA senior (Colombia) (mismo criterio de costeo de la plantilla de ejemplo).

El equipo son cuatro ingenieros de software del MISO (arquitectura y full stack), no un área QA externa. El framework de pruebas se define en la Semana 3. El corte de implementación ejecuta primero unitarias, integración/contrato, E2E, GUI y experimentos de latencia/escalabilidad sobre HA-01…HA-13. Seguridad, modificabilidad e integrabilidad permanecen diseñadas como cobertura posterior y no elevan una HU a las olas 1–4.

2.3.2. Recursos computacionales

Recurso Horas/mes Valor (COP)
4 equipos portátiles con especificaciones para desarrollo de software N/A N/A (recursos propios)
Emulador o dispositivo Android (Kotlin / Jetpack Compose) para el subconjunto core y las pruebas nativas N/A N/A (recursos propios)
Ambiente cloud para backend y experimentos de arquitectura Según Semana 3 N/A (créditos académicos / recursos propios)

Restricción: la infraestructura de pruebas del backend debe ser nube primero (sin on-premises), coherente con las restricciones de tecnología.

2.3.3. Recursos económicos para la contratación de servicios/personal

N/A. No hay presupuesto para tercerizar pruebas ni contratar personal adicional.

2.4. TNT (técnicas, niveles y tipos) de pruebas

Cada combinación TNT cubre un objetivo de la Sec. 2.1. Los niveles siguen ISTQB (unidad, integración, sistema, aceptación) y el alcance de la rúbrica (unitarias, módulo, integrales). Los tipos indican qué se evalúa (manuales, automáticas, rendimiento, usabilidad, seguridad, internacionalización). Las técnicas indican cómo se diseña y ejecuta la prueba. El detalle medible de los experimentos de arquitectura está en la Sec. 3. Las herramientas concretas se fijan en la Semana 3 (framework de pruebas).

Nivel Alcance Tipo Técnica / experimentos Objetivos
Unidad Unitarias Automáticas Pruebas unitarias automatizadas (cobertura de sentencias y ramas) sobre (1) el núcleo compartido una sola vez: Cotización, Suscripción, Pólizas, Siniestros, Pagos e Identidad (JWT); (2) presentación web (AngularJS/TypeScript con Karma, ViewModels MVVM); (3) presentación móvil (JUnit sobre Kotlin: ViewModels, casos de uso y repositorios de Clean Architecture; Compose para UI): subconjunto core, cola local y sincronización Verificar en aislamiento las reglas del dominio (sin duplicarlas por canal) y la lógica propia de cada cliente
Sistema Integrales Manuales Pruebas exploratorias: mismos recorridos core en web y móvil; más solo-web y solo-móvil Conocer el funcionamiento de Solventa y detectar defectos en el núcleo y en cada canal
Integración Módulo Automáticas Integración y contrato sobre :BFFWeb, :BFFMovil, :APISocios y API embebida, con dobles de Open Finance, Open Data, KYC y pagos. Incluye PI-01 Verificar que ambos clientes y los socios ensamblan el mismo núcleo y los terceros
Aceptación Integrales Automáticas / manuales Escenarios E2E de los seis recorridos en cada canal aplicable Validar extremo a extremo cotizar, suscribir, emitir y pagar siniestros
Sistema Integrales Automáticas Validación de datos y reglas de negocio (rating, suscripción, consentimiento, estados, idempotencia de pagos) Escenarios válidos e inválidos independientes del canal
Sistema Integrales Rendimiento PR-01, PR-02, PR-03, PR-04, PR-05 Evidencia de latencia y escalabilidad del caso (campaña 100×, originación hipotecaria, evento paramétrico, consulta de siniestro CQRS, emisión automática)
Sistema Integrales Rendimiento PD-01 p95/p99 de cotización con Open Finance sano y degradado (brazos A/B/C/C', Toxiproxy; HA-01/HA-02/HA-07)
Aceptación Integrales Usabilidad HU-25 en MVP; PD-03 completo post-mvp Conservación de evidencia sin red; posteriormente billetera offline y sincronización
Sistema Integrales Seguridad PS-01, PS-02 (fuera del corte LAT/ESC) Privacy & security by design y aislamiento entre socios
Sistema Módulo Automáticas PM-01 (fuera del corte LAT/ESC) Cambio aislado de reglas de rating sin redesplegar componentes ajenos
Aceptación Integrales Usabilidad Pruebas de GUI: paridad core web/móvil; solo-web; nativas solo-móvil (complementa PD-03) Confirmar que web y móvil no son la misma interfaz redimensionada

2.5. Distribución de esfuerzo

Asignación de las 256 h del presupuesto (Sec. 2.3) a las actividades de la Sec. 2.4. El núcleo se prueba una vez (unitarias, datos, integración). E2E y GUI cubren el recorrido en cada canal aplicable (web y/o móvil), más particularidades solo-web o solo-móvil. El momento de ejecución es el de la Sec. 2.2.

Funcionalidad Tarea Horas Recurso
Cotización embebida y rating Pruebas exploratorias (API + web; móvil si aplica) 6 John Guerrero
Pruebas unitarias (núcleo compartido) 8 John Guerrero
Integración y contrato (API / BFF Socios / BFF Web) 8 John Guerrero
Pruebas E2E (núcleo + canal socio y web) 14 John Guerrero
Validación de datos 10 John Guerrero
Pruebas de GUI (web; paridad móvil si hay consulta de oferta) 3 John Guerrero
Experimentos de arquitectura PR-01 8 John Guerrero
Experimento PL-01 (internacionalización) 3 John Guerrero
Análisis de resultados 4 John Guerrero
Suscripción, emisión y perfilamiento de vida hipotecario Pruebas exploratorias (web y móvil) 6 Mauricio Rodriguez
Pruebas unitarias (núcleo compartido) 8 Mauricio Rodriguez
Integración y contrato (Open Finance / Open Data / KYC) 8 Mauricio Rodriguez
Pruebas E2E (web, móvil y originación embebida) 14 Mauricio Rodriguez
Validación de datos 10 Mauricio Rodriguez
Pruebas de GUI (mismo flujo en web y móvil) 6 Mauricio Rodriguez
Experimentos PR-02 (3 h), PR-05 (2 h) y PS-02 (3 h) 8 Mauricio Rodriguez
Análisis de resultados 4 Mauricio Rodriguez
Siniestros asistido y paramétrico Pruebas exploratorias (web back-office y móvil con evidencia) 6 Juan Acevedo
Pruebas unitarias (núcleo compartido) 8 Juan Acevedo
Integración y contrato (pagos, IoT / eventos) 8 Juan Acevedo
Pruebas E2E (aviso web, aviso móvil, pago paramétrico) 14 Juan Acevedo
Validación de datos 10 Juan Acevedo
Pruebas de GUI (web vs móvil; cámara/push/geo en móvil) 6 Juan Acevedo
Experimentos PR-03 (2 h), PR-04 (3 h) y PD-01 (3 h) 8 Juan Acevedo
Análisis de resultados 4 Juan Acevedo
Ciclo de vida de pólizas (núcleo + web y móvil) Pruebas exploratorias (gestión web y billetera móvil) 6 Martin Romero
Pruebas unitarias (núcleo; web MVVM; móvil: ViewModels, casos de uso, Repository / Room) 8 Martin Romero
Integración y contrato (BFF Móvil / BFF Web sobre el mismo dominio) 8 Martin Romero
Pruebas E2E (ciclo de vida en web y subconjunto en móvil) 14 Martin Romero
Validación de datos 10 Martin Romero
Pruebas de GUI (paridad core web/móvil + nativas + back-office) 6 Martin Romero
Experimentos PD-03 (3 h), PS-01 (2 h), PI-01 (2 h), PM-01 (1 h) 8 Martin Romero
Análisis de resultados 4 Martin Romero
Total 256

2.6. Patrones y Lineamientos de Automatización

Para evitar que las pruebas se conviertan en deuda técnica, el framework y los scripts producidos por el equipo deben acatar:

  1. Granularidad E2E Clara: Diferenciar siempre entre Caso de Prueba (validación de un solo oráculo), Escenario de Prueba (secuencia de comportamiento del cliente) y Suite (agrupación de regresión).
  2. Behavior-Driven Development (BDD): Todo escenario E2E debe redactarse con Given-When-Then para acercar el negocio al código.
  3. PageObject Model (POM): Cero localizadores (xpath, css) dentro de los scripts de negocio. Toda interacción con AngularJS o con la UI de Jetpack Compose debe aislarse en clases de página (o equivalentes de semantics / test tags en Compose).
  4. Cero Esperas Estáticas: Está prohibido el uso de comandos sleep(). Se utilizarán únicamente dynamic waits (esperando a que un elemento esté presente en el DOM o se reciba un código 200 de la API).

2.7. Alcance negativo (fuera de esta iteración)

Explícitamente no se cubre en este ciclo de 8 semanas:

  • Todas las historias post-mvp del backlog refinado: billetera offline y su sincronización (HU-51/HU-52), autenticación biométrica y su fallback (HU-49/HU-50), mapa y cercanía de prestadores (HU-39/HU-40), asistencia en sitio (HU-41), escaneo de documentos (HU-42/HU-43), panel de socios (HU-80), autoservicio web (HU-66), orquestador maestro web (HU-67), tableros y SLAs (HU-69), pasarela de pago real (HU-21), aislamiento de cuota por socio (HU-81), monitores en vivo (HU-82) y SAST en CI/CD (HU-84).
  • Experimentos de arquitectura fuera del corte LAT/ESC (PS-01, PS-02, PI-01, PM-01, PL-01): se diseñan en la Sec. 3, pero su ejecución con evidencia queda para un corte posterior al de HA-01…HA-13.
  • Pruebas de carga contra un ambiente productivo real: los experimentos PR de campaña (PR-01) corren en el ambiente de HU-89 (aislado, destructible); PR-04 y PD-01 corren en Docker Compose local. Ninguno contra el ambiente mínimo de HU-78 ni contra un ambiente con tráfico de clientes reales.
  • Certificación regulatoria formal (Superintendencia Financiera, PCI-DSS): se prueban los stubs y adaptadores que simulan el comportamiento esperado, no la certificación real ante el regulador o el adquirente de pagos.
  • Pruebas de penetración externas (pentesting) y auditoría de seguridad por terceros: fuera del alcance de este equipo y de este ciclo.
  • Multi-región (failover entre regiones AWS distintas, EC-DISP-08): el ciclo cubre multi-AZ dentro de una región; la caída de una región completa se diseña pero no se ejecuta.

2.8. Identificación de riesgos

Riesgo Probabilidad Impacto Plan de manejo
El equipo (4 personas) no da abasto entre construir el producto y ejecutar la estrategia completa de pruebas en 8 semanas Alta Alto Priorizar unitarias + integración + E2E de los 6 recorridos críticos sobre experimentos de atributos fuera de LAT/ESC (ya reflejado en Sec. 2.3.1 y 2.7); recortar primero lo marcado post-mvp
El dataset sintético o el montaje de un experimento (p. ej. HA-08) toma más tiempo del estimado Media Medio HA-08 declara explícitamente que el esfuerzo "debe recalibrarse una vez conocida la duración real de la generación del dataset" (Guía técnica HA-08); si se materializa, se recorta el número de corridas contrabalanceadas antes que el diseño experimental. PD-01 reutiliza el Compose de HA-08: un retraso del entorno de HA-08 arrastra el laboratorio de HA-01
Los dobles/mocks de terceros (Open Finance, Open Data, KYC, pasarela) no representan fielmente la latencia o los errores del proveedor real Media Medio PD-01 inyecta fallas de red con Toxiproxy (no latencia fija en el mock) y un doble que devuelve el contrato real de OF; PR-02 sigue inyectando latencia en el mock de perfilamiento. Las amenazas a la validez se documentan en el informe (Anexo D de HA-08 como plantilla)
La tasa de acierto de :CacheOF en operación es menor que el umbral que sostiene el p99 (HD-01.4) Media Alto El experimento barre 99 % / 96 % / 90 % / 50 % para localizar el punto de quiebre; si el umbral real queda por debajo de 96 %, el informe recomienda C' o un pre-calentamiento y no se da por aceptado HA-01/HA-07
Cambios de alcance del backlog (nuevas HU u olas) durante el ciclo desalinean esta estrategia con el producto real Baja Medio Esta estrategia enlaza directamente HU/HA del backlog refinado; un cambio de backlog dispara una revisión puntual de las secciones 1.4, 2.1 y 2.4
Pruebas inestables (flaky tests) por dependencia de tiempos de red o de la UI Media Medio Mitigado por diseño: Sec. 2.6 prohíbe sleep() y exige dynamic waits y POM/test tags en ambos canales

2.9. Criterios de salida

Se suspende la ejecución de una funcionalidad o recorrido si, en cualquier punto del ciclo:

  • Más del 30 % de los casos de un recorrido crítico (Sec. 1.4) falla de forma reproducible y bloquea continuar el recorrido (p. ej. no se puede emitir póliza porque la suscripción no responde).
  • Un experimento de latencia/escalabilidad no puede montarse: PR-01 si HU-89 no está disponible; PR-04 / PD-01 si el Compose local no arranca. Se documenta como riesgo materializado (Sec. 2.8) y se re-planifica, no se fuerza una corrida sin infraestructura válida.

Se da por satisfactoriamente concluida la iteración de pruebas cuando, para el corte MVP (olas 1–4 del backlog):

  • Los 6 recorridos críticos (Sec. 1.4) tienen al menos un escenario E2E en verde por canal aplicable.
  • Las pruebas unitarias del núcleo compartido y de cada canal pasan en CI sin fallos conocidos sin resolver.
  • Los experimentos PR-01…PR-05 y PD-01 priorizados (HA-01…HA-13) cuentan con al menos una corrida documentada con veredicto (cumple / no cumple / cumple con salvedades), no necesariamente con el umbral satisfecho — el objetivo de la iteración es obtener evidencia, no garantizar que todo ASR se cumpla en este corte.
  • El informe consolidado (incidencias, evidencia, scripts, lecciones aprendidas) está disponible en el repositorio, según el objetivo 5 análogo al ejemplo de referencia del curso.

3. Tipos de pruebas

Tipos de la rúbrica Semana 2: manuales, automáticas, rendimiento, usabilidad, seguridad e internacionalización. El detalle medible son los experimentos de arquitectura (PR, PD, PS, PI, PM), alineados con las HA del backlog refinado (HA-01…HA-13) y con el TNT de la Sec. 2.4. Para las olas 1–4 se ejecutan primero los experimentos LAT/ESC; los demás quedan diseñados para el corte posterior.

Este apartado detalla esos experimentos. Semanas 4–5: propósito, respuesta esperada, tecnologías, interpretación y esfuerzo; Semanas 6–7: ejecución. El diseño completo de PR-04 vive en Diseño del experimento HA-08 y en Semana 5 §3.1. El de PD-01 vive en Semana 5 §3.2.

ID Atributo Historias Tipo (rúbrica / TNT)
PR-01 … PR-03, PR-05 Latencia / escalabilidad HA-03…HA-06, HA-09…HA-12 Rendimiento
PR-04 Latencia (consulta de siniestro, CQRS) HA-08 / EC-LAT-11 Rendimiento
PD-01 Latencia (cotización embebida, dependencia degradada) HA-01, HA-02, HA-07 / EC-LAT-01/02/09 Rendimiento
PD-03 Usabilidad (canal móvil) HU-25 (mvp), HU-51/HU-52 (post-mvp) Usabilidad
PS-01 … PS-02 Seguridad / escalabilidad HA-13, HA-21, HA-23 Seguridad
PI-01 Integrabilidad HA-31; HU-88 instala Pact en el MVP Automáticas (contrato)
PM-01 Modificabilidad HA-26 Automáticas (módulo)
PL-01 Internacionalización (localización de canales) Objetivo 3 — expansión a México, Chile y Perú (Hoja de trabajo); HU-10, HU-11 (cotización web/móvil) Automáticas (i18n)

Las herramientas de carga, caos y contrato se eligen en la Sec. 4 (framework de pruebas / EDT 3.4.1). Las tecnologías de producto (Python, nube elástica, AngularJS/TypeScript, Android Kotlin / Jetpack Compose) son el sistema bajo prueba.

3.1. Pruebas de rendimiento y escalabilidad

Validan el comportamiento bajo carga y el aprovisionamiento elástico, asegurando los presupuestos de latencia del caso.

PR-01: Escalabilidad ante picos masivos (Campaña de Socio)

  • Historias asociadas: HA-09 (50.000 cotizaciones/min durante 30 min) y HA-10 (capacidad adicional en ≤ 60 s), del backlog refinado. HA-01 y HA-02 no se aceptan aquí: su evidencia es PD-01.
  • Objetivo: Validar que el sistema escala horizontalmente y absorbe el pico de campaña de un socio sin pérdida de caudal.
  • Precondiciones: Entorno de pruebas con autoescalado habilitado. Tráfico base de 500 cotizaciones/minuto.
  • Estímulo: Inyectar un crecimiento exponencial de tráfico de 500 a 50.000 solicitudes de cotización embebida por minuto.
  • Respuesta esperada / medida:
    • El clúster provisiona nuevos nodos/contenedores en ≤ 60 segundos.
    • Sostiene 50.000 cotizaciones/min durante 30 minutos; la tasa HTTP 5xx se reporta como métrica complementaria.
    • El p95/p99 de cotización durante el pico se reporta como métrica complementaria, no como aceptación de HA-01/HA-02.
  • Tecnologías asociadas: ms-cotizacion / :MsCotización, :MotorRaiting, :APISocios / :BFFWeb, autoescalado horizontal en EKS (Sec. 4.4); generador de carga K6.
  • Interpretación: Si se sostiene el caudal y el autoescalado ≤ 60 s, se aceptan HA-09/HA-10. Una rotura de latencia durante el pico se interpreta como capacidad mínima o disparador de escala, no como veredicto de HA-01/HA-02: esos ASRs se deciden en PD-01 con el protocolo de Open Finance.
  • Esfuerzo asociado: 8 h — John Guerrero.

PR-02: Presupuesto de latencia en perfilamiento complejo

  • Historias asociadas: HA-03 (p95 ≤ 400 ms) y HA-04 (p99 ≤ 800 ms en pico de cierre de mes), del backlog refinado.
  • Objetivo: Validar el paralelismo y la orquestación de múltiples llamados externos para no superar el umbral de espera del cliente en originación hipotecaria.
  • Precondiciones: Motores de mock activos simulando latencias entre 50 ms y 200 ms para Open Data y Open Finance.
  • Estímulo: Ejecutar carga nominal y luego un pico representativo del cierre de mes; el volumen concreto se registra con la capacidad del ambiente para no introducir una meta distinta a HA-03/HA-04.
  • Respuesta esperada / medida:
    • Tiempo de respuesta del perfilamiento personalizado p95 ≤ 400 ms y p99 ≤ 800 ms de extremo a extremo.
  • Tecnologías asociadas: ms-perfilamiento / :MsPerfilamiento, :MotorRiesgo, :AdaptadorOF, :AdaptadorOD, :CacheOF / :CacheOD, mocks de terceros; generador de carga (Sec. 4.1). El fan-out paralelo de OF y OD es la táctica que hace aritméticamente viable el p95 de 400 ms (Tácticas y patrones §4).
  • Interpretación: Cumplir p95/p99 confirma paralelismo y materialización de señales. Incumplir implica serialización de llamadas o falta de caché (HA-03).
  • Esfuerzo asociado: 3 h — Mauricio Rodriguez.

PR-03: Ingesta masiva paramétrica (Contrapresión)

  • Historias asociadas: HA-11 (absorber ≥ 1.000.000 eventos en 10 min) y HA-12 (procesar el rezago exactamente una vez), del backlog refinado.
  • Objetivo: Comprobar la resiliencia de la plataforma de mensajería (event broker) ante tormentas de eventos climáticos/IoT.
  • Precondiciones: Suscriptores operando a capacidad estándar.
  • Estímulo: Inyectar 1.000.000 de eventos en un lapso de 10 minutos en los tópicos paramétricos.
  • Respuesta esperada / medida:
    • El sistema aplica contrapresión (backpressure) encolando mensajes.
    • 0% de pérdida de eventos durante la ingesta.
    • El rezago se procesa con idempotencia: 100% de eventos aplicados exactamente una vez, sin pagos duplicados.
    • Consumo asíncrono sin afectar el pool de conexiones de las bases de datos transaccionales.
  • Tecnologías asociadas: ms-parametrico / :MotorParametrico, :AdaptadorTelemetria, :TopicoTelemetria / :BusEventos (MSK o Redpanda), ms-pagos / :ColaPagos (desembolso idempotente).
  • Interpretación: Contrapresión y ≥ 1.000.000 de eventos absorbidos en 10 min evidencian HA-11; vaciar el rezago sin pérdidas ni duplicados evidencia HA-12. Pérdida o saturación de BD implica mal particionamiento o falta de idempotencia.
  • Esfuerzo asociado: 2 h — Juan Acevedo.

PR-04: Modelo de lectura de baja latencia para el estado de siniestro

Ficha resumida del experimento de arquitectura. Diseño completo (hipótesis, brazos A/B/C, staleness, amenazas a validez): Diseño del experimento HA-08 y copia final en Semana 5 §3.1. Guía de montaje: Guía técnica HA-08.

  • Historias asociadas: HA-08 (EC-LAT-11, p95 ≤ 150 ms), del backlog refinado.
  • Objetivo: Determinar el nivel mínimo de complejidad (lectura transaccional vs. proyección materializada vs. proyección + caché) que cumple el presupuesto de consulta de estado de siniestro, cuantificando el lag de proyección que se acepta a cambio.
  • Precondiciones: Dataset sintético que supera la memoria del motor; mismo binario con los tres brazos seleccionables por configuración; representación JSON idéntica en A, B y C.
  • Estímulo: Carga de consulta a tasa de llegada fija (escalones 10 / 25 / 50 / 80 req/s) con escritura concurrente (~5 eventos/s) sobre el proceso de evaluación.
  • Respuesta esperada / medida:
    • Brazo A (joins sobre siniestros_w) no alcanza p95 ≤ 150 ms en operación regular.
    • Brazo B (proyección siniestros_r) reduce el p95 de forma sustancial.
    • Brazo C (proyección + Redis) alcanza p95 ≤ 150 ms, error < 1 % y lag de proyección p95 ≤ 2 s.
    • Si B ya cumple el umbral, C es complejidad no justificada.
  • Tecnologías asociadas: API de consulta FastAPI, proyector, PostgreSQL 16 (siniestros_w / siniestros_r), Redis 7, Redpanda, K6, Prometheus/Grafana. En el modelo de producto: ms-siniestros (comando vs. consulta), :BusEventos, ElastiCache.
  • Interpretación: Cumplir p95 con el brazo más simple que lo logre acepta HA-08. Incumplir los tres brazos implica que CQRS no basta (hay que revisar serialización, pool o tasa). Un lag > 2 s indica que la consistencia eventual no es aceptable para el cliente que consulta el estado vigente.
  • Esfuerzo asociado: 3 h en esta estrategia (protocolo, umbrales K6 y lectura de evidencia). El diseño e implementación del experimento están presupuestados aparte (60 h, 15 h/integrante) en la ficha HA-08.

PR-05: Presupuesto de latencia del journey de suscripción y emisión

  • Historias asociadas: HA-05 (EC-LAT-05, p95 ≤ 1,5 s) y HA-06 (EC-LAT-06, p99 ≤ 3 s en horario pico), del backlog refinado.
  • Objetivo: Validar que firma y notificación salen del camino crítico (:BusEventos) y que :ColaPagos no bloquea la confirmación de la póliza, de modo que aceptación → póliza emitida cabe en el presupuesto.
  • Precondiciones: Dobles de pasarela y firma con latencia acotada; :MsPolizas publica el hecho y no espera consumidores.
  • Estímulo: Carga nominal y luego pico de aceptaciones concurrentes sobre el recorrido #2.
  • Respuesta esperada / medida:
    • p95 ≤ 1,5 s desde la aceptación hasta la póliza emitida (carga nominal).
    • p99 ≤ 3 s en horario pico.
    • Firma y notificación no aparecen en el tramo síncrono medido.
  • Tecnologías asociadas: ms-suscripcion, ms-polizas / :MsPolizas, ms-pagos / :ColaPagos, :AdaptadorPasarela, :BusEventos; generador de carga (Sec. 4.1).
  • Interpretación: Cumplir p95/p99 confirma la táctica de limitar la respuesta a los eventos (Tácticas y patrones §4). Si el reloj incluye firma o espera a la pasarela, el journey sigue acoplado en el camino crítico.
  • Esfuerzo asociado: 2 h — Mauricio Rodriguez.

3.2. Pruebas de resiliencia del presupuesto de latencia y del canal móvil

PD-01 es el experimento de Semana 5 que protege el presupuesto de cotización con Open Finance sano y degradado (HA-01 / HA-02 / HA-07). PD-03 cubre la usabilidad del cliente Android sin red (HU-25).

PD-01: Protección del presupuesto de latencia de la cotización embebida

Ficha resumida del experimento de arquitectura de Semana 5. Diseño completo (hipótesis HD-01.1…HD-01.8, brazos A/B/C/C', modelo de fallas, presupuesto de borde): Experimento 2 — HA-01. Es la evidencia de la pregunta 3 del enunciado (MISW4501-202614-Proyecto §6.1): cómo se protege el presupuesto de latencia de la cotización cuando el proveedor de Open Finance es más lento e impredecible.

  • Historias asociadas: HA-01 (EC-LAT-01, p95 ≤ 250 ms e2e), HA-02 (EC-LAT-02, p99 ≤ 500 ms e2e) y HA-07 (EC-LAT-09, p95 ≤ 250 ms con dependencia degradada), del backlog refinado. Restricciones: EC-LAT-07 (≤ 120 ms por dependencia) y EC-LAT-08 (timeout duro de 700 ms). HU-5/HU-88 proveen el stub y el ambiente.
  • Objetivo: Determinar el nivel mínimo de desacople (invocación bloqueante vs. caché con espera en fallo vs. actualización oportunista vs. coalescencia) que cumple el presupuesto de cotización con el proveedor sano y también degradado, cuantificando la frescura del dato y la proporción de cotizaciones resueltas con valor de respaldo.
  • Precondiciones: Mismo binario de :MsCotización con los cuatro brazos seleccionables por configuración; montaje sin :ApiGateway (los umbrales se trasladan al servicio descontando el presupuesto de borde del Anexo G); :CacheOF con política de expiración por fuente; doble del proveedor que devuelve el contrato real de Open Finance; Toxiproxy entre :AdaptadorOF y el doble. :Consentimiento es precondición de la salida a Open Finance en el modelo de componentes, no una variable de este experimento.
  • Estímulo: Carga de cotización a tasa de llegada fija (k6) combinada con (1) estrategia de resolución del perfil — brazos A bloqueante sin caché, B cache-aside que espera al proveedor en fallo, C actualización oportunista + valor de respaldo, C' = C más coalescencia (single-flight) —, (2) cinco estados del proveedor más recuperación (sano, lento, degradado, sin respuesta, caído), (3) tasas de acierto de caché 99 % / 96 % / 90 % / 50 %, y (4) política del interruptor (umbral por conteo vs. por tasa sobre ventana) en tráfico alto y bajo.
  • Respuesta esperada / medida:
    • p95 ≤ 225 ms y p99 ≤ 475 ms medidos en el servicio (equivalentes a 250 ms / 500 ms extremo a extremo una vez sumado el presupuesto de borde del Anexo G).
    • Con el proveedor sano, A, B y C cumplen el p95 (HD-01.1).
    • Con el proveedor degradado, solo el brazo C cumple p95 y p99 (HD-01.2).
    • En C, el camino degradado es más rápido que el camino frío con proveedor sano (HD-01.3).
    • C sostiene el umbral con tasa de acierto ≥ 96 %; por debajo, el p99 se degrada (HD-01.4).
    • Peticiones sacrificadas hasta la apertura del interruptor < 1 % de la ventana con tráfico alto (HD-01.5).
    • Se reportan como costo: edad del perfil usado y proporción de cotizaciones con respaldo.
  • Tecnologías asociadas: :MsCotización, :MotorRaiting (costo calibrado ~60 ms), :CacheOF (Redis 7), :AdaptadorOF (httpx con bulkhead, timeout 700 ms, interruptor propio). Instrumentación (no arquitectura): doble FastAPI del contrato OF, Toxiproxy, k6, Prometheus/Grafana. Docker Compose V2 reutilizado de HA-08. El montaje no incluye :ApiGateway.
  • Interpretación: El brazo más simple que cumple con el proveedor sano y degradado acepta HA-01/HA-02/HA-07 y responde la pregunta 3: la llamada a Open Finance es actualización oportunista, no dependencia bloqueante (Tácticas y patrones §4). Si C falla, la caché oportunista no basta (hay que revisar pool, interruptor o umbral de acierto). Si B ya cumple degradado, C es complejidad no justificada. C' se adopta solo si HD-01.7 muestra estampida sin coalescencia.
  • Esfuerzo asociado: 3 h en esta estrategia (protocolo, umbrales k6 y lectura de evidencia). El diseño e implementación del laboratorio están presupuestados aparte (56 h, 14 h/integrante) en Semana 5 §3.2.8.

PD-03: Tolerancia a desconexión del cliente (modo offline)

  • Historias asociadas: HU-25 (conservar evidencia sin red, mvp) y HU-51/HU-52 (billetera offline y sincronización, post-mvp) del backlog refinado.
  • Objetivo: Validar la sincronización asíncrona y el almacenamiento local del cliente móvil (usabilidad / canal, no ASR de latencia ni de escalabilidad).
  • Precondiciones: Cliente móvil autenticado (JWT validado en :BFFMovil), con caché local inicializada (Room).
  • Estímulo: Corte de conectividad de red en el móvil → captura de siniestro con evidencia → reconexión.
  • Respuesta esperada / medida:
    • Las capas Data (Repository + Room) y WorkManager aseguran el guardado de captura y evidencia cifrada localmente; el ViewModel no habla con red ni con Room.
    • Al recuperar la red, los datos se sincronizan aplicando idempotencia (cero avisos duplicados). Las pruebas manuales/usabilidad comprobarán la respuesta visual.
  • Tecnologías asociadas: cliente Android (Kotlin / Jetpack Compose, Clean + MVVM + Repository), :BFFMovil, ms-siniestros, Room, WorkManager.
  • Interpretación: En el MVP, persistencia local y envío idempotente de la evidencia aceptan HU-25. La consulta y sincronización de billetera se ejecutan cuando entren HU-51/HU-52.
  • Esfuerzo asociado: 3 h — Martin Romero.

3.3. Pruebas de seguridad

Garantizan protección de datos, mínimo privilegio y cumplimiento normativo (Ley 1581, Finanzas Abiertas, PCI-DSS en pagos).

PS-01: Bloqueo de ataques en línea y aislamiento por socio

  • Historias asociadas: HA-13 (aislamiento de cuota) y HA-23 (bloqueo de patrón anómalo), del backlog refinado. HA-13/HU-81 son post-mvp; el experimento no ordena las olas 1–4.
  • Objetivo: Validar las políticas del API Gateway (rate limiting, cuotas y detección de anomalías).
  • Precondiciones: API Gateway configurado con cuotas específicas por tenant (socio).
  • Estímulo: Un socio (o atacante) excede intencionalmente su cuota enviando miles de peticiones malformadas o un ataque DoS (capa 7).
  • Respuesta esperada / medida:
    • Patrón anómalo bloqueado (HTTP 429 / 403) en ≤ 1 segundo.
    • El exceso de carga no afecta el presupuesto de latencia del resto del sistema (aislamiento de carga efectivo).
  • Tecnologías asociadas: :ApiGateway / :APISocios, WAF, ms-identidad (JWT + RBAC), cuotas por socio.
  • Interpretación: 429/403 en ≤ 1 s evidencia HA-23; conservar el p95 de los socios no infractores evidencia HA-13. Contagio de latencia implica falta de aislamiento en el gateway.
  • Esfuerzo asociado: 2 h — Martin Romero.

PS-02: Propagación de revocación de consentimiento

  • Historia asociada: HA-21 (revocación efectiva en ≤ 5 min), relacionada con HU-46/HU-53 en el backlog refinado.
  • Objetivo: Confirmar que la arquitectura basada en eventos propaga la revocación de acceso a los datos de forma centralizada (privacy by design).
  • Precondiciones: Múltiples proyecciones de lectura pobladas con datos de un cliente.
  • Estímulo: El cliente revoca su consentimiento desde la aplicación.
  • Respuesta esperada / medida:
    • Evento de revocación publicado y procesado por todos los consumidores en ≤ 5 minutos.
    • Consultas subsecuentes desde módulos analíticos y cotizadores tienen 0% de visibilidad sobre esos datos.
  • Tecnologías asociadas: ms-consentimiento, :BusEventos, proyecciones de ms-cotizacion / analítica.
  • Interpretación: Cero visibilidad en ≤ 5 min evidencia HA-21. Datos residuales en proyecciones exigen revisar consumidores y políticas de retención.
  • Esfuerzo asociado: 3 h — Mauricio Rodriguez.

3.4. Pruebas de integración y contratos de APIs

PI-01: Evolución de API sin romper clientes (backwards compatibility)

  • Historia asociada: HA-31; HU-88 instala dobles y Pact en el MVP, según el backlog refinado.
  • Objetivo: Asegurar que los componentes (canal web, app móvil, API socios) confíen en contratos estables (patrón BFF o versionado de API).
  • Precondiciones: Cliente web y móvil consumiendo la versión v1.
  • Estímulo: Despliegue de la versión v2 de la API central con cambios en la estructura de entidades subyacente.
  • Respuesta esperada / medida:
    • Pruebas de contrato controladas por el consumidor (consumer-driven contract tests) pasan.
    • Coexistencia de versiones permitida arquitectónicamente sin forzar actualizaciones (0 despliegues simultáneos forzados).
  • Tecnologías asociadas: :BFFWeb / :BFFMovil / :APISocios, contratos de API, versionado; herramienta de contrato (Sec. 4.1). El JWT se emite en ms-identidad y se valida en el BFF; un cambio de app no redespliega el emisor.
  • Interpretación: Contratos verdes y v1 viva evidencian HA-31. Rotura de clientes implica acoplamiento al modelo interno o falta de versionado.
  • Esfuerzo asociado: 2 h — Martin Romero.

3.5. Pruebas de modificabilidad

PM-01: Modificación en caliente del motor de reglas (rating)

  • Historia asociada: HA-26, relacionada con HU-4 en el backlog refinado.
  • Objetivo: Comprobar el bajo acoplamiento arquitectónico separando la lógica actuarial de los componentes de orquestación (alta cohesión).
  • Precondiciones: Sistema operando con reglas versión A.
  • Estímulo: Se inyecta la versión de reglas B para recalcular primas.
  • Respuesta esperada / medida:
    • El cambio se aplica de forma versionada sin redesplegar componentes ajenos al motor de rating.
    • Cero interrupciones en flujos de cotización que no utilicen esas reglas.
  • Tecnologías asociadas: ms-cotizacion / :MotorRaiting, ms-catalogo.
  • Interpretación: Cambio contenido y versionado evidencia HA-26. Redesplegar componentes ajenos al rating implica reglas acopladas a la orquestación.
  • Esfuerzo asociado: 1 h — Martin Romero.

3.6. Pruebas de internacionalización (i18n / l10n)

Validan que la capa de presentación (web y móvil) esté preparada para la expansión a México, Chile y Perú (Objetivo 3 de la hoja de trabajo), sin tocar el núcleo (Python), que es agnóstico de idioma y solo maneja moneda y locale como datos.

PL-01: Localización de moneda, fecha y textos en los canales de cliente

  • Historias asociadas: Objetivo 3 (expansión a México, Chile y Perú); HU-10 (cotización web) y HU-11 (cotización móvil) del backlog refinado, por ser las primeras pantallas que muestran prima y moneda al cliente.
  • Objetivo: Verificar que ningún texto, formato de fecha, número o moneda queda hardcodeado en un locale único (es-CO), y que el cambio de locale no requiere modificar el núcleo de cotización.
  • Precondiciones: Catálogo de recursos de idioma cargado para al menos dos locales (es-CO y es-MX o es-CL/es-PE); el backend entrega prima y moneda como datos (ya lo hace HU-6), no como texto formateado.
  • Estímulo: Cambiar el locale del cliente (web: selector de idioma/región; móvil: configuración de idioma del dispositivo) y repetir el recorrido de cotización.
  • Respuesta esperada / medida:
    • El 100 % de los textos visibles en pantalla proviene del catálogo de recursos del locale activo (cero cadenas literales en el código de presentación).
    • Montos se formatean con el símbolo y separador decimal/miles del locale (ej. $1.234,56 en es-CO vs. $1,234.56 en otro locale) sin cambios en el backend.
    • Fechas se formatean según el locale (dd/mm/aaaa vs. mm/dd/aaaa) sin cambios en el backend.
    • Cambiar de locale no dispara ningún redespliegue ni cambio en ms-cotizacion (coherente con HA-25).
  • Tecnologías asociadas: Web — @angular/localize o ngx-translate sobre AngularJS/TypeScript, verificado con Karma. Móvil — recursos strings.xml/plurals.xml por locale sobre Android Kotlin/Jetpack Compose, verificado con JUnit + Compose UI Test (LocalConfiguration de prueba).
  • Interpretación: Catálogo completo + formato correcto de moneda/fecha por locale evidencia que el canal está listo para la expansión regional del Objetivo 3. Cadenas o formatos fijos en el código de presentación, o cualquier cambio requerido en el núcleo, indican acoplamiento del idioma/región a la lógica de negocio.
  • Esfuerzo asociado: 3 h — John Guerrero (repartido: 1.5 h validación web, 1.5 h validación móvil).

4. Frameworks y ambientes

4.1. Framework para pruebas

1. Pruebas de Extremo a Extremo (E2E) - Multiplataforma

Para validar los 6 recorridos críticos simulando el uso real (Validación) en Web y Móvil, cada canal usa su propio stack (repositorios separados):

  • Web: Cucumber + Gherkin. Detalle en Sec. 4.2.
  • Móvil: JUnit E2E de Jetpack Compose. Detalle en Sec. 4.3.
  • Justificación: Los escenarios BDD (Given / When / Then) se mantienen como lineamiento transversal (Sec. 2.6); la ejecución E2E queda en el runner nativo de cada cliente (Cucumber en AngularJS/TypeScript, JUnit Compose en Android/Kotlin), sin un orquestador multiplataforma adicional.

2. Pruebas de Integración y Contrato (Módulo)

Para el experimento PI-01 (Evolución de API sin romper clientes) y la validación del núcleo en Python:

  • Herramienta: PyTest (Python) integrado con Pact (para pruebas de contrato impulsadas por el consumidor - CDC).
  • Justificación: PyTest verificará la correcta implementación de las reglas del motor de rating (Verificación), mientras que Pact nos asegurará que las modificaciones en el core no rompan los contratos esperados por :BFFWeb, :BFFMovil o :APISocios. El JWT se valida en el BFF, no en el emisor (ms-identidad).

3. Pruebas de Rendimiento y Escalabilidad (Experimentos PR y PD-01)

Para validar los atributos de latencia y absorción de picos (PR-01, PR-02, PR-03, PR-04, PR-05, PD-01):

  • Herramienta: K6 (de Grafana) o JMeter; Toxiproxy para inyectar fallas de red en PD-01.
  • Justificación: K6 permite escribir los scripts de carga en JavaScript y simular tanto las 50.000 solicitudes/minuto de PR-01 como la tasa de llegada fija de PR-04 y PD-01 (imprescindible para no enmascarar el p95 cuando el servicio se degrada). Los umbrales del ASR se declaran en el propio script. Toxiproxy degrada la conexión TCP en caliente, que es el modo de falla que EC-LAT-09 describe; un delay dentro del mock simularía un servidor lento, no una red degradada.

4. Validación Visual (VRT - Visual Regression Testing)

Para confirmar que AngularJS y Android (Jetpack Compose) no son simplemente la misma interfaz redimensionada:

  • Herramienta: Resemble.js o BackstopJS.
  • Justificación: Capturará los árboles de pintado y la jerarquía de los componentes, fallando la prueba si el umbral de diferencia visual supera lo definido en nuestra línea base.

5. Pruebas de Internacionalización (i18n / l10n)

Para el experimento PL-01, alineado con el Objetivo 3 (expansión a México, Chile y Perú):

  • Herramienta: @angular/localize / ngx-translate en el canal web; recursos strings.xml por locale + JUnit/Compose UI Test en el canal móvil.
  • Justificación: Ambas herramientas permiten activar un locale de prueba distinto al de desarrollo (es-CO) sin tocar el núcleo Python, verificando que textos, moneda y fecha se resuelven por catálogo de recursos y no quedan fijos en el código de presentación.

4.2. Framework para el componente web

El cliente web se desarrolla en AngularJS con TypeScript. El stack de pruebas del canal web es:

  • E2E / BDD: Cucumber, con escenarios escritos en Gherkin (Given / When / Then), alineado con los lineamientos de la Sec. 2.6. Cubre cada recorrido crítico que tenga historia web mvp: venta asistida, suscripción/emisión, back-office de siniestros, perfilamiento y comandos/reportes internos de póliza. Tableros y panel de socios se prueban cuando entren las HU post-mvp.
  • Unitarias: pruebas unitarias de AngularJS y TypeScript, ejecutadas con Karma (cobertura de sentencias y ramas de la lógica de presentación, componentes y servicios del cliente).
  • Internacionalización: @angular/localize (o ngx-translate) como framework de i18n, con catálogo de recursos por locale (es-CO, es-MX, es-CL, es-PE). Se prueba con Karma (PL-01): cero cadenas literales en componentes, formato de moneda y fecha resuelto por Intl/pipes de Angular según el locale activo.
  • Justificación: Cucumber acerca el lenguaje de negocio a los recorridos web sin acoplar los scripts a localizadores. Karma es el test runner del canal AngularJS/TypeScript en CI, de modo que las unitarias del cliente y las de i18n se ejecutan de forma aislada del núcleo Python.

4.3. Framework para el componente móvil

El cliente móvil se desarrolla en Android (Kotlin) con Jetpack Compose, según las capas documentadas (Clean Architecture + MVVM + Repository). El stack de pruebas del canal móvil es:

  • E2E: JUnit E2E para Jetpack Compose (createAndroidComposeRule / Compose UI Test). En el MVP cubre cotización, aceptación/póliza, aviso de siniestro con foto y geoetiqueta, conservación de evidencia sin red, paramétrico, perfilamiento y avisos del ciclo de vida. Biometría, billetera offline, mapa, asistencia y escaneo quedan post-mvp.
  • Unitarias: JUnit por capa, independientes de emulador cuando no hay UI: ViewModels (estado), casos de uso del Domain, y *RepositoryImpl (remoto Retrofit → :BFFMovil vs. local Room). Cola local e idempotencia; billetera y sincronización cuando entren HU-51/HU-52.
  • Internacionalización: recursos de Android por locale (res/values-es-rMX, res/values-es-rCL, res/values-es-rPE, strings.xml/plurals.xml) como framework de i18n. Se prueba con Compose UI Test forzando LocalConfiguration a cada locale (PL-01): cero cadenas fijas en Composables, formato de moneda y fecha resuelto por NumberFormat/DateFormat según el locale activo.
  • Justificación: JUnit es el runner nativo de Android. Las APIs de prueba de Compose validan la UI declarativa con semántica y test tags, sin xpath/css ni esperas estáticas, coherente con POM y dynamic waits de la Sec. 2.6. Probar ViewModel, caso de uso y repositorio por separado evita que el ViewModel hable con red o con Room, que es la regla de la arquitectura.

4.4. Ambiente cloud para backend, herramientas de test

Proveedor: AWS, coherente con la restricción de nube pública, con la vista de despliegue Semana 5 (VPC, EKS, RDS, ElastiCache, MSK, WAF, KMS) y con la fortaleza del equipo en Terraform/AWS (Mauricio, Juan, Martin — ver Story point estimate). Es el mismo proveedor de HU-78 (red y clúster mínimo), de modo que ambos ambientes comparten patrón de IaC.

Ambiente de experimentos (HU-89), distinto del despliegue mínimo de HU-78:

Elemento Definición
Cómputo EKS (grupo de autoescalado acotado 1→4 réplicas) para ms-cotizacion / :MsCotización en PR-01. Alineado al modelo de despliegue; no se usa ECS Fargate.
Red VPC dedicada de pruebas, aislada del ambiente mínimo de HU-78, provisionada con Terraform
Base de datos RDS Postgres (o contenedor efímero si el experimento no requiere persistencia real). PR-04 usa PostgreSQL 16 local con esquemas siniestros_w / siniestros_r; PD-01 usa PostgreSQL 16 solo para cargar reglas de tarifa al arranque (fuera del camino crítico)
Caché y bus ElastiCache Redis y MSK en el modelo de producto; Redis 7 + Redpanda en el montaje local de HA-08; Redis 7 (:CacheOF) en el de HA-01
Aprovisionamiento 100 % IaC (Terraform) para el ambiente cloud; Docker Compose V2 para PR-04 y PD-01 (reproducible en estación de desarrollo; PD-01 extiende el Compose de HA-08 con Toxiproxy y el doble OF). Destructible después de cada corrida
Costo Créditos académicos de AWS; sin gasto fijo declarado al no mantenerse el ambiente encendido entre corridas
Herramientas de test K6 (tasa de llegada y umbrales declarativos) para PR-01 … PR-05 y PD-01; Toxiproxy para los cinco estados del proveedor en PD-01; Prometheus/Grafana para correlacionar p95, lag de proyección y hit-rate en PR-04, y estado del interruptor sobre la curva de latencia en PD-01

Justificación: un ambiente separado del despliegue mínimo evita que la carga de K6 contamine la evidencia funcional de HU-78. El autoescalado acotado (1→4 réplicas en EKS) es suficiente para ejercitar el umbral de 60 s de HA-10 sin sobredimensionar créditos académicos. PR-04 y PD-01 se corren en Docker Compose para fijar CPU/memoria por componente y comparar brazos en igualdad de recursos; el montaje de PD-01 no incluye :ApiGateway. La ejecución y evidencia concreta se registra como parte de HU-89 · Ambiente cloud de experimentos (PR-01) y de los spikes HA-08 / HA-01 en el tablero SOLV.