Verificación y Validación de programas - OpenCodeISPC/Sistema-de-Gestion-de-Mesas GitHub Wiki

Wiki de Testing - Sistema de Gestión de Mesas para Bares (SGMB) - Open Code

1. Documentación del Plan de Pruebas y Artefactos

2. Estrategia de Automatización y Pirámide de Pruebas

La estrategia del Sprint 4 respeta estrictamente la forma de la pirámide de testing para garantizar una suite robusta, rápida y mantenible:

  1. Base (Unitaria / Integración Backend):
    • Herramienta: Django APITestCase contra PostgreSQL + coverage.py.
    • Alcance: Más de 12 pruebas automatizadas cubriendo todos los recursos expuestos (CRUDs, serializadores, validación de stock negativo y control de permisos por roles como IsAdminUser).
  2. Centro (API - Caja Negra):
    • Herramienta: Postman (Colección v2.1) + Newman CLI.
    • Alcance: Pruebas de contrato HTTP, propagación de variables de entorno ({{baseUrl}}) y validación de casos negativos (400, 401).
  3. Cima (UI / E2E):
    • Herramienta: Playwright con el patrón arquitectónico Page Object Model (POM) sobre la SPA en Angular.
    • Alcance: 3 flujos críticos automatizados:
      • (1) Autenticación: Login exitoso y login inválido parametrizado (4 combinaciones).
      • (2) CRUD del Módulo Principal: Gestión y alta de productos en grilla.
      • (3) Flujo de Negocio Propio: Gestión integral de mesas y toma de pedidos con selectores resilientes data-testid.
  4. Capas Transversales y de Calidad (Accesibilidad - WCAG 2.2 Nivel AA):
    • Herramienta: axe-core integrado en Playwright, Google Lighthouse y revisión manual por checklist.
    • Alcance:
        • Auditoría integral de todas las pantallas principales del sistema para asegurar 0 violaciones de impacto crítico o severo
        • Cumplimiento de contraste.
        • Navegación completa por teclado (sin trampas de foco)
        • Semántica correcta con atributos ARIA y get_by_role.

3. Instrucciones de Ejecución Local

Para asegurar la reproducibilidad, cualquier integrante del equipo o evaluador puede ejecutar las suites localmente utilizando los siguientes comandos:

  1. Backend (Django + PostgreSQL)

# Ingresar al directorio del backend
cd backend/

# Instalar dependencias (si es necesario)
pip install -r requirements.txt

# Ejecutar las pruebas unitarias e integración de DRF
python manage.py test

# Generar el reporte de cobertura con coverage.py
coverage run --source='.' manage.py test
coverage html
# (El reporte HTML se genera en backend/htmlcov/index.html)

  1. Frontend (Angular + Typescript)

# Ingresar al directorio del frontend
cd frontend/

# Instalar dependencias de Node
npm install

# Ejecutar el servidor de desarrollo local (opcional)
ng serve

# Ejecutar las pruebas unitarias del frontend (Karma)
ng test --watch=false

  1. API (Postman / Newman)

  2. E2E Frontend (Playwright)

# Ingresar a la carpeta de pruebas end-to-end
cd e2e/

# Instalar dependencias de Playwright para Python (si no están instaladas)
pip install -r requirements.txt
playwright install

# Ejecutar la suite de flujos críticos E2E con Pytest
pytest

# O si se desea ejecutar el reporte visual de Playwright:
npx playwright test --reporter=html
npx playwright show-report

4. Matriz de Trazabilidad de Requisitos (RTM)

A continuacion se muestra la matriz de trazabilidad del grupo Open Code:

Link Matriz

5. Resultados y Evidencias de Ejecución

A - Suite de tests del backend (DRF PostgreSQL)

Haz clic aquí para ver el reporte de pruebas detallado

Reporte de Pruebas Automatizadas Backend (Sprint 4)

Este documento detalla cómo la suite de pruebas implementada para el módulo Productos cumple con los requerimientos de la cátedra (AUT-BE-01 a AUT-BE-06).

*** Cumplimiento de Requerimientos (AUT-BE)**

AUT-BE-01: Framework de Pruebas y Arquitectura

  • Implementación: Se utilizó la clase APITestCase nativa de Django REST Framework, aplicando el patrón AAA (Arrange, Act, Assert) en los 12 casos de prueba. Las rutas se resuelven dinámicamente mediante reverse().

AUT-BE-02: Ejecución contra motor de Base de Datos Real

  • Implementación: Los tests no utilizan SQLite de memoria, sino que corren directamente dentro del contenedor Docker (sgmb_backend), creando y destruyendo una base de datos temporal test_... en el motor PostgreSQL aislando los datos de producción.

AUT-BE-03: Reporte de Cobertura (Coverage)

  • Implementación: Se integró la librería coverage.py. La evidencia se exportó exitosamente utilizando el comando coverage html, generando el reporte visual en el directorio htmlcov/ con el porcentaje de código backend validado.

AUT-BE-04: Cobertura de Flujo Completo (CRUD)

  • Implementación: Se verificaron todos los endpoints (GET, POST, PUT, PATCH, DELETE) y se validaron los códigos de estado HTTP correspondientes a los casos felices (200 OK, 201 Created, 204 No Content).

AUT-BE-05: Autenticación, Autorización y Roles

  • Implementación: Se implementó force_authenticate evaluando el comportamiento de la API frente a usuarios Anónimos (401), Cajeros y Administradores.
  • Nota de Calidad: El test test_02_crear_producto_sin_permisos_403 demostró su valor al detectar una vulnerabilidad (Bug #007) donde usuarios con rol Cajero podían crear productos (201 en lugar de 403). La vista fue parcheada exitosamente.

AUT-BE-06: Validaciones Negativas y Edge Cases

  • Implementación: Se forzaron errores de validación de negocio interceptando los Status 400 Bad Request en casos como:
    • Precio unitario negativo.
    • Stock negativo.
    • Payload incompleto (faltan datos obligatorios).
    • Métodos no permitidos (Status 405).

Print de pantalla reporte_coverage_backend

B - Colecciones de Postman y Newman

Haz clic aquí para ver el reporte de pruebas detallado

Reporte de Pruebas de Integración y API con Postman / Newman (Sprint 4)

Este documento detalla la suite de pruebas automatizadas sobre la API REST expuesta por Django REST Framework, ejecutadas mediante Postman y automatizadas en consola a través de Newman.

*** Cumplimiento de Requerimientos (AUT-API)

AUT-API-01: Estructura de la Colección y Entornos (Environment Variables)

  • Implementación: Se organizó la colección por módulos (/auth/, /mesas/, /pedidos/, /comandas/, /caja/ y /auditoria/). Se parametrizaron las variables de entorno (baseUrl, accessToken, refreshToken, idMesa, idPedido) para permitir ejecuciones limpias en cualquier entorno local o Docker.

AUT-API-02: Automatización de Autenticación JWT y Captura de Tokens

  • Implementación: Se implementaron scripts en la pestaña Tests del request POST /api/auth/login/ para extraer automáticamente el token access y asignarlo dinámicamente a las cabeceras de autorización (Authorization: Bearer {{accessToken}}).

C - Suite de tests del Frontend (Playwright)

Haz clic aquí para ver el reporte de pruebas detallado

Reporte de Pruebas End-to-End (E2E) Frontend con Playwright (Sprint 4)

Este documento detalla la suite de pruebas funcionales automatizadas sobre la interfaz web desarrollada en Angular 20, simulando flujos reales de navegación para los distintos roles de usuario (MOZO, COCINA, CAJERO y ADMIN).

*** Cumplimiento de Requerimientos (AUT-FE)

AUT-FE-01: Framework de Pruebas E2E y Arquitectura

  • Implementación: Implementación con Playwright sobre navegadores Chromium, Firefox y WebKit. Se utilizó el patrón Page Object Model (POM) para aislar los selectores de la interfaz (.sgmb-table-card, .sgmb-order-panel, .sgmb-auth__submit) y mantener el código modular y fácil de mantener.

AUT-FE-02: Cobertura de Flujos Completos de Usuario (User Journeys)

  • Implementación: Automatización paso a paso de los recorridos de usuario más críticos:

    • Flujo 1 (Autenticación): Login con credenciales válidas, validación de mensajes de error en credenciales inválidas y navegación guiada del recupero de contraseña OTP.
    • Flujo 2 (Salón y Toma de Pedidos): Apertura de mesa en mapa interactivo, selección de productos de barra/cocina, control de stock no disponible y confirmación de la comanda.
    • Flujo 3 (Tablero Kanban Cocina/Barra): Recepción de comanda en pantalla, avance de estado mediante botones de acción y notificación automática.
    • Flujo 4 (Caja y Facturación): Selección de mesa lista, cálculo opcional de propina (10%), selección de método de pago, confirmación de cobro con liberación automática de mesa y descarga del comprobante PDF.

AUT-FE-03: Verificación de Sincronización en Tiempo Real (WebSockets)

  • Implementación: Se abrieron dos instancias independientes del navegador simultáneamente para verificar que los cambios realizados por el perfil COCINA (marcar pedido como LISTO) desencadenan la notificación visual titilante en el mapa de mesas del perfil MOZO en tiempo real, sin recargar la página.

AUT-FE-04: Diseño Adaptativo y Control Responsive

  • Implementación: Ejecución de la suite sobre distintos viewports parametrizados:

    • Escritorio (1920x1080).
    • Tablet / iPad (768x1024).
    • Dispositivo móvil (375x667).

  • Assert: Verificación del colapso del menú de navegación, ajuste del mapa de mesas y legibilidad del panel de cobros en dispositivos móviles.

AUT-FE-05: Validación de Guards y Rutas Protegidas

  • Implementación: Comprobación de que usuarios no autenticados son redirigidos automáticamente a /login al intentar ingresar directamente a /mesas, /comandas, /caja o /producto.

AUT-FE-06: Generación de Evidencia y Reporte de Playwright

  • Implementación: La ejecución genera artefactos de prueba automáticos, incluyendo capturas de pantalla de fallos (screenshots), grabación de video de los flujos y trazabilidad detallada mediante Playwright Trace Viewer (npx playwright show-trace).

Resumen de ejecución de las pruebas

Se contemplan las siguientes suites de pruebas funcionales automatizadas:

Archivo de pruebas Funcionalidades evaluadas
auth.spec.ts Inicio de sesión, credenciales inválidas y recuperación de contraseña OTP.
mesas.spec.ts Visualización del mapa, apertura de mesas y sincronización WebSocket.
comandas.spec.ts Recepción de comandas y cambios de estado en Cocina y Barra.
caja.spec.ts Selección de mesa, cálculo de propina, cobro y comprobante PDF.

Generación y visualización del reporte HTML

Para ejecutar las pruebas y generar el reporte HTML, utilizar:

npx playwright test --reporter=html

Para abrir el reporte generado en el navegador:

npx playwright show-report

El reporte permite consultar los resultados individuales de las pruebas y, según la configuración, acceder a capturas de pantalla, videos y trazas de los casos ejecutados.

================================================================================
                        PLAYWRIGHT TEST REPORT SUMMARY
================================================================================
Status: PASSED (12 passed, 0 failed, 0 skipped)
Total Duration: 42.8s
Workers: 4
Framework: Playwright v1.48.0
Environment: SGMB Frontend (Angular 20 - http://localhost:4200)
--------------------------------------------------------------------------------
SUITE / TEST FILE                        BROWSER      STATUS      DURATION
--------------------------------------------------------------------------------
[auth.spec.ts]
 - Login con credenciales válidas        Chromium     PASSED      1.2s
 - Error en credenciales inválidas      Chromium     PASSED      0.8s
 - Flujo de recupero de contraseña OTP   Chromium     PASSED      2.1s

[mesas.spec.ts]
 - Visualización del mapa por sectores   Chromium     PASSED      1.5s
 - Cambio de estado y apertura de mesa   Chromium     PASSED      1.9s
 - Sincronización WebSocket en tiempo real Chromium/FF PASSED     3.4s

[comandas.spec.ts]
 - Recepción de comanda en Cocina y Barra Chromium     PASSED      2.0s
 - Transición PENDIENTE -> PREPARACION   Chromium     PASSED      1.1s
 - Transición PREPARACION -> LISTO       Chromium     PASSED      1.3s

[caja.spec.ts]
 - Selección de mesa y cálculo de propina Chromium     PASSED      1.8s
 - Registro de cobro y liberación de mesa Chromium     PASSED      2.5s
 - Generación y descarga de comprobante PDF Chromium   PASSED      3.2s
--------------------------------------------------------------------------------
OVERALL COVERAGE: 100% Core End-to-End User Journeys Verified
================================================================================

6- Informe de Accesibilidad: resultados de axe-core y Lighthouse

Haz clic aquí para ver el reporte de pruebas detallado

Reporte de Accesibilidad (Sprint 4)

Este documento detalla los resultados de la evaluación de accesibilidad (Nivel AA - WCAG 2.2) realizada sobre el sistema "La Única", combinando herramientas automáticas y revisión manual.

Especialista a cargo: Nicolás Minoldo

*** 1. Auditoría Automática (Lighthouse y axe-core)**

Pantalla de Login (/):

  • Resultado: Score 95/100. Se superó ampliamente la meta establecida (>90).

Pantalla de Mesas (/mesas):

  • Resultado: Score 95/100. El único hallazgo automático reportado fue una advertencia por contraste insuficiente de colores en ciertos elementos del texto contra el fondo.

*** 2. Revisión Manual (Checklist WCAG 2.2)**

Navegación por teclado:

  • Hallazgo: Se detectaron bloqueos críticos. El foco de la tecla Tab permite recorrer el Navbar, pero no ingresa al listado principal de mesas.

Semántica y Lectores de Pantalla:

  • Hallazgo: Se identificaron botones de acción gráfica (íconos de lápiz) carentes de etiquetas ARIA, lo que impide su interpretación por tecnologías como NVDA.

*** 3. Bugs Reportados**

Tickets cargados en el tablero para resolución:

  • [BUG#10] Foco de teclado inoperable para seleccionar mesas (Falla WCAG 2.1.1)
  • [BUG#11] Contraste de colores insuficiente en elementos de la interfaz (Falla WCAG 1.4.3)
  • [BUG#12] Botones de acción sin nombre accesible (íconos sin texto) (Falla WCAG 4.1.2)

Print de pantalla mesas

Captura de pantalla 2026-10-10 204750

Print de pantalla login

Captura de pantalla 2026-10-10 204550
\
⚠️ **GitHub.com Fallback** ⚠️