Contexto de la estrategia de pruebas S5 - JohannPaezU/MISW4501-MediSupply GitHub Wiki

2. Contexto de la Estrategia de Pruebas

2.1. Objetivos

2.1.1. Desarrollar pruebas unitarias sobre los componentes del backend de la aplicación web de MediSupply, con el fin de verificar el correcto funcionamiento de cada función, clase o módulo de forma aislada. Estas pruebas permitirán validar la lógica de negocio implementada en servicios como gestión de pedidos, validaciones de inventario, cálculo de rutas y control de entregas.

2.1.2. Desarrollar pruebas de integración automatizadas que permitan identificar defectos relacionados con la interacción entre los distintos módulos del sistema, como inventario, ventas, logística y gestión de clientes. Estas pruebas asegurarán que los componentes colaboren correctamente para cumplir con los requisitos funcionales.

2.1.3. Desarrollar pruebas end-to-end (E2E) que simulen flujos completos desde la perspectiva del usuario, incluyendo escenarios como inicio de sesión, creación de pedidos, consulta de inventario, asignación de rutas logísticas y seguimiento de entregas. Estas pruebas permitirán validar que el sistema cumple con los requisitos funcionales definidos en las épicas y features del proyecto.

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

El proceso de pruebas se desarrollará de forma iterativa, incremental y paralela al ciclo de desarrollo, desde el 29 de octubre de 2025 hasta el 21 de noviembre de 2025, cubriendo tanto la fase de arquitectura como la de desarrollo del prototipo. Se divide en dos etapas principales:

Etapa 1 – Refinamiento de la Estrategia de Pruebas

Duración: Semanas 2 a 8 (11 de agosto – 28 de septiembre 2025)

Actividades:

  • Definir y documentar la estrategia de pruebas (unitarias, integración, E2E).
  • Establecer criterios de aceptación por historia de usuario (HU).
  • Diseñar casos de prueba iniciales para funcionalidades core.
  • Configurar el entorno de pruebas y herramientas de automatización.
  • Establecer convenciones de cobertura, naming y estructura de carpetas.
  • Priorizar flujos críticos para pruebas E2E en etapas posteriores.

Etapa 2 – Ejecución Iterativa de Pruebas Funcionales

Duración: Semanas 9 a 16 (6 de octubre – 21 de noviembre 2025)

  • Cada integrante del equipo dedicará 1 hora por semana a tareas de pruebas.
  • Con un equipo de 4 personas, se contará con 4 horas semanales para:
    • Escribir pruebas unitarias para nuevos servicios.
    • Implementar pruebas de integración para interacciones entre módulos.
    • Ejecutar y depurar pruebas E2E en staging.
    • Registrar y hacer seguimiento a defectos detectados.
  • La planificación de pruebas será contextual a cada HU entregada en el sprint.
  • Se mantendrá un backlog de pruebas automatizadas que crecerá progresivamente.

2.3. Presupuesto de pruebas

2.3.1. Recursos Humanos

Equipo:

  • Miguel Fernando Padilla Espino
  • Johann Sebastián Páez Campos
  • Julián Oliveros Forero
  • Juan Sebastián Cervantes Restrepo

Cada miembro tendrá una dedicación de 1 hora semanal exclusivamente para pruebas, sumando un total de 4 horas-hombre por semana para construcción, ejecución y mantenimiento del plan.

Perfil técnico del equipo:

  • Formación profesional en Ingeniería de Software o áreas afines.
  • Participación en la asignatura de Pruebas Automatizadas (Maestría Uniandes).
  • Conocimiento en pruebas unitarias, integración, E2E y regresión.
  • Experiencia con Jest, Pytest, Cypress, Playwright.
  • Conocimiento en CI/CD, pruebas en microservicios, diseño de casos, Git.

Tecnologías y herramientas clave:

  • Frontend Web: Angular 17, PrimeNG, Angular Material, ngx-translate
    Jest, Karma, Angular Testing Library
  • Backend: Python + FastAPI (microservicios)
    Pytest, unittest, HTTPX + TestClient, pyJWT
  • BD: PostgreSQL (scripts + fixtures para validación)
  • App móvil: Kotlin (foco parcial en esta fase)
  • CI/CD: GCP + Kubernetes + GitHub Actions

2.3.2. Recursos Computacionales

Infraestructura en la nube (Google Cloud Platform):

  • GKE (Kubernetes Engine)
  • Cloud Run / App Engine
  • Cloud Load Balancing
  • Google Maps API
  • Cloud SQL (PostgreSQL)
  • Cloud Storage

Equipos personales de los desarrolladores:

  • CPU: Intel i5+ / M1 / Ryzen 5+
  • RAM: 8GB (mínimo), mayoría 16GB
  • SO: Windows 10/11, macOS, Ubuntu 22.04+
  • Herramientas: VS Code, PyCharm, Docker, navegadores modernos, DevTools
  • Conexión: Banda ancha (>50 Mbps)
  • Limitación: No hay dispositivos móviles dedicados para pruebas

El entorno mixto (cloud + local) permite orquestar pruebas automatizadas de forma efectiva sin incurrir en costos adicionales de infraestructura.

2.3.3. Recursos Económicos

No se contempla la contratación de personal externo. El equipo interno asumirá todas las actividades de pruebas.

Presupuesto para servicios en la nube:

  • GKE (entornos escalables de prueba)
  • Cloud SQL (bases de datos gestionadas)
  • Cloud Storage (reportes, logs, backups)
  • Cloud Run / App Engine (despliegue temporal)
  • Google Maps API (ruteo)
  • Cloud Load Balancer (simulación de tráfico concurrente)

2.4. TNT (Técnicas, Niveles y Tipos de prueba)

Estrategia adoptada:

  • Enfoque por niveles: unidad, integración, sistema, aceptación
  • Pruebas automatizadas y manuales combinadas

Cobertura:

  • Backend: Python/FastAPI
  • Frontend: Angular
  • Móvil: Kotlin (parcial)
  • E2E: Cypress / Playwright / Espresso
  • Aceptación: checklist manual + validación HU
Nivel Tipo de Prueba Técnica Componente Objetivo
Unidad Funcional Automatizada (Pytest, JUnit) Backend (FastAPI), Android 2.1.1
Unidad Caja blanca Automatizada Backend 2.1.1
Integración Funcional Automatizada (HTTPX, TestClient, Supertest) API Gateway, microservicios 2.1.2
Integración Caja negra Automatizada Backend/API 2.1.2
Sistema (Web) Funcional Automatizada (Cypress, Playwright) Aplicación Web (Angular) 2.1.3
Sistema (Android) Funcional Automatizada (Espresso) Aplicación Móvil (Kotlin) 2.1.3
Sistema (Web/Mob) Caja negra Automatizada Web + Android 2.1.3
Sistema Seguridad Manual y automatizada (headers, auth, roles) Web + Backend 2.1.3
Sistema Internacionalización Manual (Herramienta de traducción Chrome) Aplicación Web y Móvil 2.1.3
Aceptación Funcional Manual (Checklist + Validación HU) Web + Android 2.1.3
Aceptación Caja negra Manual Web + Android 2.1.3

2.5. Distribución de Esfuerzo

Modelo de automatización adoptado: Pirámide de Pruebas

  • 60% pruebas unitarias
  • 25% pruebas de integración
  • 10% pruebas end-to-end (E2E)
  • 5% pruebas de aceptación/manuales

Carga total estimada: 4 horas semanales (1h por integrante)
Duración total: 8 semanas de ejecución de pruebas (del 29 de octubre al 21 de noviembre 2025)

Distribución por Nivel y Porcentaje de Esfuerzo

Nivel de Prueba % del Esfuerzo Actividades Clave Responsables
Unidad 60% Cobertura de servicios críticos: autenticación, inventario, pedidos, cálculo de rutas. Backend Devs
Integración 25% Validar comunicación entre microservicios: logística ↔ bodega, ventas ↔ inventario. Backend + QA
E2E 10% Simulación de escenarios completos: creación de pedido, asignación de ruta, entrega, notificaciones. QA + Fullstack
Aceptación/Manual 5% Validación funcional contra HU y criterios de aceptación; pruebas de i18n y seguridad. QA Lead + Product Owner

Distribución por Semana y Entregables

Semana Sprint/Etapa Horas Totales (4h) Tareas Detalladas Entregables
9 Inicio ejecución iterativa 4h (1h c/u) - Configuración de entornos de CI/CD para pruebas.- Escribir pruebas unitarias de Autenticación.- Validación inicial de endpoints. Reporte cobertura inicial (Pytest)
10 Unidad 4h (1h c/u) - Pruebas unitarias de Inventario y Pedidos.- Validación de fixtures BD.- Configurar mocks. Suite de pruebas unitarias crítica
11 Integración 4h (1h c/u) - Pruebas API Gateway ↔ Logística.- Flujos Inventario ↔ Bodega.- Automatización HTTPX/TestClient. Informe bugs inter-servicios
12 Integración + Móvil 4h (1h c/u) - Pruebas integración móvil.- Validar endpoints desde app Kotlin.- Configurar pruebas Espresso. Casos integrados + evidencias
13 E2E Web 4h (1h c/u) - Flujo completo: login → pedido → logística.- Cypress/Playwright: scripts.- Validación UI. Escenarios E2E automatizados
14 E2E + Internacionalización 4h (1h c/u) - Pruebas i18n web/móvil.- Validar traducciones y formatos.- Ajuste pruebas E2E. Evidencias i18n + ajustes
15 Seguridad + Performance 4h (1h c/u) - Pruebas de seguridad (roles, tokens).- Configuración básica carga concurrente en GCP. Reporte de seguridad preliminar
16 Cierre y Regresión 4h (1h c/u) - Ejecución regresión completa.- Consolidar métricas de cobertura y defectos. Informe final de pruebas

Distribución del Esfuerzo por Rol

Rol Actividades Principales
Backend Devs Pruebas unitarias, integración microservicios, refactor de servicios.
QA Engineer Pruebas E2E, escenarios funcionales, documentación, regresión.
Fullstack Dev Ajustes frontend/móvil y pruebas integradas con APIs.
Product Owner / QA Lead Validación aceptación HU, checklist manual, priorización defectos.

Priorización de HU para Pruebas

HU (Jira) Funcionalidad Prioridad Nivel de Prueba
SCRUM-71 Registro proveedores y productos Alta Unidad + Integración
SCRUM-75 Generación rutas entrega Alta Unidad + Integración + E2E
SCRUM-54 Pedido en línea + inventario Alta Integración + E2E
SCRUM-55 Video y recomendación Media Unidad + Integración
SCRUM-47 Consulta estados pedidos Media E2E + Aceptación
Resto HU Funciones soporte (usuarios, reportes) Baja Unitarias y checklist manual

Con esta planificación, cada sprint tiene entregables claros (suite de pruebas, reporte, cobertura) y asignación de carga semanal explícita. Esto ayuda a rastrear avance y medir calidad del sistema.

2.6. Análisis de la Gráfica de Distribución de Esfuerzo

La siguiente gráfica resume de forma visual cómo se distribuye el esfuerzo del equipo durante las semanas 9 a 16:

Enlace en HD: https://github.com/user-attachments/assets/19e82d9b-8e06-46d4-8717-d5c76231520b

  • Distribución de esfuerzo por roles (arriba izquierda): Se observa una participación equilibrada de todos los roles (Backend Devs, QA Engineer, Fullstack Dev, Product Owner/QA Lead), cada uno aportando una hora semanal. Esto asegura que cada sprint tenga cobertura técnica, validación funcional y priorización estratégica.

  • Horas por semana (arriba derecha): Se mantiene una carga constante de 4 horas semanales para actividades de pruebas, lo que facilita la planificación y el seguimiento de avances.

  • Distribución de prioridades de HU (abajo izquierda): La mayoría de historias de usuario son de alta prioridad, enfocadas en funcionalidades críticas como pedidos, inventario y rutas de entrega. Esto refleja un enfoque en la calidad de los módulos de mayor impacto.

  • Distribución de niveles de prueba (abajo derecha): Destaca que 40% del esfuerzo se dedica a pruebas unitarias e integración, reforzando la base de la pirámide de pruebas. Los escenarios E2E y aceptación ocupan 20% cada uno, lo que equilibra pruebas automáticas y manuales.

En conjunto, esta gráfica respalda que la estrategia de pruebas se alinea con buenas prácticas: foco en pruebas unitarias, automatización progresiva, priorización de funcionalidades críticas y balance de carga por rol.