Contexto de la estrategia de pruebas S1 - 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: Pirámide de Pruebas
Pruebas por sprint: Planificadas según funcionalidades entregadas

Distribución por Etapas

Etapa 1 – Refinamiento de la Estrategia

Duración: Semanas 2 a 8
Dedicación semanal total: 4 horas (1h por integrante)

Actividades:

  • Criterios de aceptación por HU
  • Diseño de estrategia y casos core
  • Configuración de entornos y herramientas (Pytest, Cypress, Espresso)
  • Priorización de flujos críticos

Etapa 2 – Ejecución Iterativa

Duración: Semanas 9 a 16
Dedicación semanal total: 4 horas (1h por integrante)

Actividades por semana:

  • Semana 9–10: Pruebas unitarias (autenticación, inventario, pedidos)
  • Semana 11–12: Flujos E2E web, pruebas funcionales móviles
  • Semana 13–14: Pruebas integración logística-bodega, validación HU, Pruebas de Internacionalización
  • Semana 15–16: Flujo E2E completo, análisis de cobertura, Pruebas de Seguridad, cierre

Las pruebas se alinearán con las funcionalidades listas por sprint.