✅ Fase de Evaluación - Resultados y Verificación

Esta sección describe la estrategia de pruebas aplicada y los resultados que demuestran el cumplimiento de los requerimientos de la Kata Middle Developer.


Estrategia de Pruebas

Para garantizar la estabilidad de la PoC, se implementó una estrategia de pruebas en múltiples niveles:

1. Pruebas de Calidad Automática (Criterios Kata)

El sistema ha sido validado contra los escenarios propuestos en el reto:

Criterio Validación Resultado
Cobertura ≥ 80% El Rules Engine bloquea releases con cobertura inferior. Verificado
Estructura Validación obligatoria de descripción y existencia de PR/JIRA. Verificado
Obsolescencia El sistema detecta versiones EOL vía API externa. Verificado

Resultados de Pruebas Funcionales

Escenario A: Aprobación Automática Exitosa

  • Entrada: Cobertura 92%, PR válido, framework Node.js 22.x.
  • Proceso: El motor de reglas valida los 3 criterios sin fallos.
  • Resultado: Estado APPROVED_AUTO, persistencia en DB exitosa, sin notificaciones de error.

Escenario B: Bloqueo por Cobertura Insuficiente

  • Entrada: Cobertura 65%, PR válido.
  • Proceso: Regla de calidad detecta déficit (65% < 80%).
  • Resultado: Estado PENDING, aviso preventivo en Dashboard y envío de email al aprobador.

Escenario C: Detección de Obsolescencia

  • Entrada: Stack con Node.js 12.x (EOL).
  • Proceso: Consulta a endoflife.date confirma que la versión no tiene soporte.
  • Resultado: Estado PENDING con detalle: Frameworks obsoletos: Node.js 12.22.0 (End of Life).

Pruebas de Integración y Rendimiento

  • GitHub API: Verificación exitosa de Pull Requests existentes (404 controlado para inexistentes).
  • Persistencia: Operaciones CRUD validadas en PostgreSQL con tiempos de respuesta < 50ms.
  • Latencia UI: El dashboard reactivo carga las métricas en < 1s gracias al uso de Signals.
  • Notificaciones: Emails recibidos en Mailtrap con el detalle exacto de las reglas fallidas.

Cumplimiento de Requerimientos No Funcionales

  1. Seguridad: Ofuscación completa de tokens de API y credenciales de base de datos en la documentación pública.
  2. Arquitectura: Verificación de desacoplamiento; el fallo en el servicio de notificaciones no impide el registro del release.
  3. Auditabilidad: El Audit Log registra correctamente la diferencia entre aprobaciones por sistema y aprobaciones justificadas.

[!IMPORTANT] Todos los casos de prueba unitaria para el motor de reglas han superado el 100% de éxito, garantizando la confiabilidad del sistema de aprobación automática.


Volver arriba

© 2026 Banco de Bogotá - Optimización de Ciclo de Vida de Software

This site uses Just the Docs, a documentation theme for Jekyll.