Entrega Semana 3 - AndersenCastanedaUniAndes/proyecto-1 GitHub Wiki
Escenarios de Calidad y Priorización
Seguridad
Escenario 1: Emisión y Firma de JWT
| Atributo |
Descripción |
| Fuente |
Cliente (Hospital / Laboratorio) |
| Estímulo |
Hacer login |
| Artefacto |
Sistema |
| Ambiente |
Operación normal |
| Respuesta |
El sistema valida la autenticidad del usuario y genera un JWT |
| Medida de la respuesta |
Todos los tokens deben generarse en ≤1 segundo, estar firmados y expirar en un máximo de 15 minutos para reducir el riesgo de uso indebido. |
Historias de Usuario asociadas
Escenario 2: Control de acceso al sistema basado en roles
| Atributo |
Descripción |
| Fuente |
Cliente (Hospital o Laboratorio) |
| Estímulo |
Usuario intenta acceder a un recurso protegido. |
| Artefacto |
Sistema |
| Ambiente |
Operación normal |
| Respuesta |
El sistema valida el JWT recibido y aplica control de acceso basado en roles y permisos sobre el recurso solicitado. |
| Medida de la respuesta |
Accesos validados con JWT: sin token → 401; sin permisos → 403; con permisos → 2xx. Todos los endpoints protegidos y accesos denegados auditados |
Historias de Usuario asociadas
Disponibilidad
Escenario 1: Disponibilidad en tiempo real de productos en inventario
| Atributo |
Descripción |
| Fuente |
Gerente de cuenta |
| Estímulo |
Consultar disponibilidad de productos en tiempo real |
| Artefacto |
Sistema |
| Ambiente |
En operación normal |
| Respuesta |
El sistema debe verificar en tiempo real la existencia de los productos y mostrar su disponibilidad |
| Medida de la respuesta |
Debe funcionar El 99.95% de las veces |
Historias de Usuario asociadas
MED-65 - HU - Inventario: Consulta de stock con alta precisión (Backend)
MED-66 - HUA - Alta disponibilidad del sistema de inventario
Escenario 2: Consultar estado de un pedido durante eventos sanitarios
| Escenario 2 |
Versión 1 |
| Fuente |
Cliente (Hospital o Laboratorio) |
| Estímulo |
Consultar el estado de un pedido |
| Artefacto |
Sistema |
| Ambiente |
Durante evento sanitario |
| Respuesta |
El sistema debe verificar en tiempo real el estado del pedido y mostrar su estado |
| Medida de la respuesta |
Debe funcionar El 99.95% de las veces |
Historias de Usuario asociadas
Escalabilidad
Escenario 1: Manejo de Picos de Usuarios Concurrentes
| Atributo |
Descripción |
| Fuente |
Gerente de TI |
| Estímulo |
Incremento en el número de usuarios concurrentes durante una campaña sanitaria |
| Artefacto |
Sistema |
| Ambiente |
Durante una campaña de vacunación o emergencia sanitaria |
| Respuesta |
El sistema debe manejar hasta 400 usuarios concurrentes por minuto sin degradar el rendimiento |
| Medida de la respuesta |
El sistema escala para procesar hasta 400 requests por minuto |
Historias de Usuario asociadas
Escenario 2: Aumento en Volumen de Transacciones
| Atributo |
Descripción |
| Fuente |
Director de Operaciones |
| Estímulo |
Incremento en el volumen de transacciones de pedidos |
| Artefacto |
Sistema |
| Ambiente |
Durante eventos de alta demanda, como brotes epidémicos |
| Respuesta |
El sistema debe procesar hasta 400 pedidos por minuto sin fallos |
| Medida de la respuesta |
El sistema escala para procesar hasta 400 pedidos por minuto |
Historias de Usuario asociadas
Latencia
Escenario 1: Respuesta en tiempo real de productos en inventario
| Atributo |
Descripción |
| Fuente |
Gerente de cuenta |
| Estímulo |
Consultar el inventario de un producto en tiempo real |
| Artefacto |
Sistema |
| Ambiente |
En operación normal |
| Respuesta |
El sistema debe verificar en tiempo real la existencia del producto y mostrar su disponibilidad |
| Medida de la respuesta |
Debe responder en ≤2 segundos |
Historias de Usuario asociadas
MED-66 - HUA - Alta disponibilidad del sistema de inventario
Escenario 2: Consultar el estado de un pedido
| Escenario 2 |
Versión 1 |
| Fuente |
Cliente (ospital o Laboratorio) |
| Estímulo |
Consultar el estado de un pedido |
| Artefacto |
Sistema |
| Ambiente |
Durante evento sanitario |
| Respuesta |
El sistema debe verificar en tiempo real el estado de un pedido |
| Medida de la respuesta |
Debe responder en ≤1 segundos |
Historias de Usuario asociadas
Historias de Usuario priorizadas
Enlace a Jira
Velocidad del equipo
Capacidad del grupo en términos de HU
Estrategia de Pruebas
Aplicación Bajo Pruebas
- Nombre Aplicación: MedySupply
- Versión: 1.0
Descripción
La Plataforma MediSupply, disponible en versión web y móvil, está diseñada para soportar de manera integral los procesos de compras, inventarios, logística, ventas y gestión de clientes dentro de un entorno de alta disponibilidad (7x24x365), con tiempos de respuesta ágiles (≤ 2 segundos en operaciones críticas), altos estándares de seguridad y la capacidad de evolucionar tecnológicamente conforme a las necesidades del negocio.
Actualmente, MediSupply enfrenta retos importantes en la administración de su cadena de suministro médico, tales como la falta de integración entre inventarios y la demanda proyectada, pérdidas recurrentes por vencimiento de productos y la desconexión entre las áreas de ventas, compras y logística. Estas limitaciones impactan directamente en la eficiencia operativa, incrementan los costos y ponen en riesgo el cumplimiento de los objetivos estratégicos de la compañía.
Funcionalidades Core
-
Compras:
- Registro de proveedores y productos.
- Optimización de compras mediante algoritmos.
- Gestión de certificaciones sanitarias y condiciones tributarias.
-
Inventarios:
- Consulta en tiempo real de inventario.
- Gestión de lotes y fechas de vencimiento.
- Alertas automáticas para productos próximos a vencer.
-
Logística:
- Generación de rutas óptimas para entregas.
- Seguimiento en tiempo real de envíos.
- Validación de cadena de frío.
-
Ventas:
- Creación y seguimiento de pedidos.
- Recomendaciones de productos basadas en datos históricos.
- Gestión de clientes institucionales.
-
Gestión de Clientes:
- Registro y autenticación de clientes.
- Historial de pedidos y preferencias.
- Notificaciones y alertas personalizadas.
Diagramas
Diagrama de Contexto
Diagrama de Arquitectura
Modelo de Datos
Contexto de la estrategia de pruebas
Objetivos
| ID |
Objetivo |
| OB1 |
Validar que el sistema maneje 400 usuarios concurrentes sin degradar el rendimiento (tiempo de respuesta ≤ 2 segundos en el 99% de las transacciones). |
| OB2 |
Asegurar que el sistema procese 400 pedidos por minuto durante picos de demanda sin fallos. |
| OB3 |
Verificar que las alertas de cadena de frío se generen y envíen en menos de 2 segundos. |
| OB4 |
Garantizar que el sistema cumpla con los estándares de seguridad, incluyendo autenticación multifactor y cifrado de datos sensibles. |
| OB5 |
Validar la integración con sistemas externos (pagos, geolocalización, IoT) sin errores. |
| OB6 |
Asegurar que el sistema mantenga una disponibilidad de ≥99,95% durante el periodo de pruebas. |
| OB7 |
Confirmar que las rutas logísticas se generen en menos de 3 segundos para 200 vehículos concurrentes. |
| OB8 |
Verificar que el sistema permita la creación masiva de productos (10,000 productos/hora) sin errores. |
| OB9 |
Validar que el 100% de los endpoints/pantallas administrativas exijan permisos explícitos y que accesos sin permiso reciban 403 en el 100% de los casos, medido en la suite de pruebas de aceptación. |
| OB10 |
Validar que el 100% de los logs de auditoría sean inmutables y solo accesibles por usuarios con privilegios autorizados. |
Duración de la iteración de pruebas:
- Fecha de inicio: 1/Octubre/2025
- Fecha de fin: 30/Noviembre/2025
- Horas planeadas: 90 horas (4 semanas, 12 horas/semana)
Presupuesto de pruebas
| Concepto |
Costo Total USD |
| Recursos Humanos |
18000 |
| Herramientas y Licencias |
2700 |
| Servicios Externos |
3000 |
| Total |
23700 |
Recursos Humanos
| Rol |
Cantidad |
Experiencia Relevante |
Tiempo Disponible (horas/semana) |
| Líder de Pruebas |
1 |
1 año en pruebas de software, experiencia en pruebas de rendimiento y seguridad. |
80 |
| Analista de Pruebas Funcionales |
2 |
1 año en pruebas funcionales, experiencia en herramientas como Selenium y JIRA. |
80 |
| Analista de Pruebas de Rendimiento |
1 |
1 año en pruebas de rendimiento, experiencia con JMeter y LoadRunner. |
80 |
| Analista de Seguridad |
1 |
1 año en pruebas de seguridad, experiencia en OWASP ZAP y Burp Suite. |
80 |
Recursos Computacionales
- Equipos de Desarrollo y Pruebas
- Computadoras para Desarrollo y Pruebas:
- Especificaciones:
- Procesador: Intel Core i5 / AMD Ryzen 7 o superior.
- Memoria RAM: 16 GB mínimo (32 GB recomendado para pruebas de rendimiento).
- Almacenamiento: 512 GB SSD o superior.
- Sistema Operativo: Windows 10 / macOS / Linux (Ubuntu 20.04 o superior).
- Cantidad: 4 equipos (2 para desarrollo backend, 2 para desarrollo móvil, 2 para pruebas automatizadas).
- Dispositivos Móviles para Pruebas:
- Modelos: Dispositivos Android (Samsung Galaxy S22, Google Pixel 6) e iOS (iPhone 13, iPad Air).
- Cantidad: 4 dispositivos (2 Android, 2 iOS).
Herramientas de Pruebas
- Frameworks para Pruebas:
- Cypress: Para pruebas end-to-end en aplicaciones web.
- Jest: Para pruebas unitarias y de integración en JavaScript (React).
- Pytest: Para pruebas unitarias y de integración en Python (backend).
- Flutter driver: Para pruebas de integración en aplicaciones móviles desarrolladas con Flutter.
- Herramientas de Rendimiento:
- JMeter: Para pruebas de carga y estrés en APIs y servicios backend.
- Herramientas de Accesibilidad:
- i18n: Para pruebas de internacionalización y accesibilidad en aplicaciones web y móviles.
Entorno de Desarrollo
- Lenguajes de Programación:
- Python: Para el desarrollo del backend.
- Dart: Para el desarrollo de aplicaciones móviles con Flutter.
- Typescript: Para el desarrollo de aplicaciones front-end con React
- Control de Versiones:
- Git: Para el control de versiones del código fuente.
- GitHub Actions: Para la integración y despliegue continuo (CI/CD).
Infraestructura en la Nube
- Google Cloud Platform (GCP):
Kubernetes: Para la orquestación de contenedores en entornos de producción y pruebas.
Docker: Para la creación y gestión de contenedores de aplicaciones.
PostgreSQL: Base de datos relacional para almacenar la información del sistema.
Frameworks de Desarrollo
- Web:
- React: Framework para el desarrollo de la interfaz de usuario web.
- React-i18next: Para la internacionalización de la aplicación web.
- Móvil:
- Flutter: Framework para el desarrollo de aplicaciones móviles multiplataforma.
- flutter_i18n: Para la internacionalización de la aplicación móvil.
Recursos Adicionales
- Herramientas de Colaboración:
- Slack / Microsoft Teams: Para la comunicación del equipo.
- Jira : Para la gestión de tareas y seguimiento de proyectos.
TNT (Técnicas, Niveles y Tipos) de pruebas:
| Nivel |
Tipo |
Técnica |
Objetivo (ID) |
| Pruebas Unitarias |
Funcionales |
Pruebas automatizadas con pytest |
OB1, OB2 |
| Pruebas de Integración |
Funcionales |
Pruebas de APIs con Postman |
OB5 |
| Pruebas de Sistema |
Rendimiento |
Pruebas de carga con JMeter |
OB1, OB2 |
| Pruebas de Sistema |
Seguridad |
Pruebas de penetración con OWASP ZAP |
OB4, OB9 |
| Pruebas de Sistema |
Usabilidad |
Pruebas con usuarios reales |
OB6 |
| Pruebas de Aceptación |
Funcionales |
Pruebas manuales con clientes |
OB3, OB7 |
| Pruebas de Regresión |
Funcionales |
Automatizadas con Cypress |
OB8 |
| Pruebas de Sistema |
Seguridad / Auditoría |
Validación de logs con scripts automáticos + revisión manual |
OB10 |
Distribución de Esfuerzo
| Actividad |
Responsable |
Fecha Inicio |
Fecha Fin |
Esfuerzo (horas) |
| Diseño de casos de prueba |
Líder de Pruebas |
01/10/2025 |
10/10/2025 |
20 |
| Ejecución de pruebas unitarias |
Analista Funcional 1 |
11/10/2025 |
20/10/2025 |
30 |
| Pruebas de integración |
Analista Funcional 2 |
21/10/2025 |
30/10/2025 |
25 |
| Pruebas de rendimiento |
Analista de Rendimiento |
02/11/2025 |
11/11/2025 |
40 |
| Pruebas de seguridad |
Analista de Seguridad |
12/11/2025 |
20/11/2025 |
30 |
| Pruebas de usabilidad |
|
|
|
|
| Líder de Pruebas |
21/11/2025 |
25/11/2025 |
20 |
|
| Pruebas de aceptación con clientes |
Analista Funcional 1 |
26/11/2025 |
30/11/2025 |
25 |
Las pruebas unitarias se ejecutan de manera cíclica durante los 3 sprints del proyecto. Aunque se asigna un bloque específico de tiempo en el cronograma para su ejecución inicial, estas pruebas se repiten e iteran en cada sprint durante el desarrollo de las historias de usuario para asegurar la calidad continua del código y validar que las nuevas funcionalidades implementadas se despliegan correctamente.
Definición de frameworks y ambientes
Framework para Pruebas
- Cypress
- Jest
- Pytest
- flutter_driver
Framework para Web
Framework para Móvil
Ambiente Cloud
- GCP
- Kubernetes
- Docker
- PostgreSQL
- JMeter
Desarrollo
- Python (backend)
- Typescript (web)
- Dart (móvil)
- Git
- Github Actions (CI/CD)
Accesibilidad
Tablero de trabajo
Seguimiendo del proyecto
Vídeo con evidencias
Enlace a vídeo en VoiceThread