Skip to content

Testing.md

Jump to bottom
PereyraHebe edited this page Oct 16, 2026 · 16 revisions

Wiki: Plan de Pruebas de Software — Granja Avícola NV

Documento Plan de Pruebas

Plan de pruebas SharkCode

Planilla de casos de prueba

Planilla de casos de prueba SharkCode

Reporte de Bugs

Reporte de bugs SharkCode

1. Información General y Equipo

  • Proyecto: Plataforma web Granja Avícola NV con sistema de gestión integrado.
  • Organización de Desarrollo: Shark Code.
  • Cliente: Nahuel Vilar (Propietario de la granja).
  • Patrocinador: ISPC.
  • Versión del Plan: 1.0.0 (14/09/2026).
  • Stack Tecnológico: Frontend en Angular, backend en Django REST Framework, persistencia políglota con PostgreSQL (Aiven) y MongoDB Atlas.

Matriz de Roles y Responsabilidades

Integrante Rol Principal Módulo Asignado para Casos y Ejecución
Jorge Marchisone Líder de Proyecto / QA Capa de persistencia de datos (PostgreSQL / MongoDB) y pruebas automatizadas del módulo ‘Ventas y pedidos’
Hebe Pereyra Líder de Pruebas / QA Portal web público (Landing page) y elaboración del plan y pruebas automatizadas del módulo ‘Gestión y reportes’
Lautaro Barrera QA / Testing Módulo de finanzas (compras y gastos operativos) y pruebas automatizadas del módulo 'Producción'
Mariela Suárez QA / Testing Módulo de ventas y pedidos, elaboración del plan y pruebas automatizadas del módulo 'Autenticación y seguridad'
Victoria Picco QA / Testing Módulo de autenticación y seguridad, elaboración del plan y pruebas automatizadas del módulo 'Finanzas'

2. Alcance de las Pruebas

Módulos Incluidos (In Scope)

  • Autenticación y Seguridad: Login con JWT, recuperación de contraseña, cierre de sesión, Route Guards en Angular y permisos por rol en Django REST Framework.
  • Producción (Mobile-First): Carga rápida en galpón (< 3 min), recolección de maples clasificados (color y tamaño), registro de mermas (roturas) y bajas sanitarias (descuento del censo avícola).
  • Finanzas (Egresos): Registro ágil de gastos operativos menores (combustible, insumos, mantenimiento) y filtros por fecha.
  • Ventas y Pedidos: Alta rápida de clientes, agendamiento de pedidos semanales, trazabilidad de reparto y estados de cobro (entregado/abonado).
  • Reportes y Balances: Visualización consolidada semanal (ingresos vs. egresos).
  • Portal Web Público: Landing page informativa (bienestar animal, recetas) y derivación directa a WhatsApp.
  • Persistencia: Integridad transaccional en PostgreSQL y colecciones de contenido en MongoDB Atlas.

Exclusiones Explícitas (Out of Scope) y Riesgos Asumidos

  • E-commerce / Pasarelas de pago: Venta directa manual hasta escalar a 10.000 aves. Riesgo: desajustes manuales en arqueos.
  • Logística y Optimización GPS: Distribución empírica por el cliente sin Google Maps. Riesgo: ineficiencias en traslados y combustible.
  • Checklist con fotos y reporte edilicio: Comunicación verbal o WhatsApp ante incidentes. Riesgo: falta de trazabilidad visual centralizada.
  • Alertas automatizadas de frescura de stock: Rotación física en depósito. Riesgo: potenciales despachos desfasados si falla el control manual.
  • Servidor SMTP (emails automáticos): Sin blanqueo autónomo ni correos transaccionales; reseteos manuales vía DB por el admin.
  • Pruebas de carga y estrés masivo: Justificado por base operativa actual acotada (25 clientes frecuentes).

3. Estrategia y Tipos de Pruebas

  • Enfoque general: Pruebas predominantemente manuales basadas en casos de prueba predefinidos con datos representativos.
  • Pruebas Funcionales y de Integración: Verificación de flujos end-to-end entre Angular, Django REST Framework y las bases de datos.
  • Pruebas de API REST: Ejecución y validación de endpoints, códigos de estado HTTP y payloads mediante Postman e interfaz de Django.
  • Pruebas de Seguridad y Roles: Restricciones de acceso (Admin vs. Operario con acceso exclusivo a producción móvil y bloqueo 403 a finanzas).
  • Pruebas de Responsividad / Mobile-First: Validación estricta de usabilidad en dispositivos móviles para operarios de galpón.
  • Pruebas de Regresión: Reejecución tras correcciones o cambios en backend/frontend para evitar efectos colaterales.
  • Pruebas automatizadas: se implementarán pruebas de backend con Django REST Framework (APITestCase), pruebas de API con Postman y Newman, y pruebas end-to-end (E2E) con Playwright.
  • Pruebas de accesibilidad: se evaluará el cumplimiento de criterios WCAG 2.2 AA mediante axe-core, Lighthouse y verificaciones manuales de navegación por teclado, contraste y adaptación de la interfaz.
  • Cobertura de código: se utilizará coverage.py para analizar la cobertura de las pruebas automatizadas del backend.

4. Criterios de Aceptación, Suspensión y Reanudación

  • Criterios de Aceptación:
    • 100% de las funcionalidades críticas probadas.
    • 0 defectos críticos o bloqueantes abiertos.
    • Defectos de prioridad alta corregidos y re-verificados.
    • Consistencia y persistencia íntegra en PostgreSQL y MongoDB.
    • Comportamiento mobile-first validado sin errores de visualización ni concurrencia.
  • Criterios de Suspensión:
    • Presencia de bugs bloqueantes que frenen la ejecución general.
    • Caída de entorno, backend o indisponibilidad de bases de datos.
    • Detección de pérdida o corrupción de datos.
  • Criterios de Reanudación: Corrección verificada del error causante, entorno restablecido y ejecución de regresión sobre las áreas impactadas.

Estrategia de Automatización de Pruebas — Granja Avícola NV

1. Pirámide de Testing y Distribución de Capas

Nuestra estrategia de verificación y validación sigue el modelo de la Pirámide de Automatización, priorizando pruebas rápidas, aisladas y de bajo costo en la base (Backend), validando los contratos de comunicación en el centro (API) y reservando las pruebas sobre navegador para los flujos críticos de negocio (E2E).

               / \
              /   \       Cúspide: UI / E2E (Playwright + POM) -> 3 Flujos Críticos
             /-----\
            /       \     Centro: API / Caja Negra (Postman + Newman) -> 1 Colección CRUD
           /---------\
          /           \   Base: Backend / Unitarias e Integración (Django APITestCase) -> 15 Tests
         /-------------\

Detalle de la Pirámide por Capa

Capa de la Pirámide Qué se prueba en Granja NV Herramienta Cantidad / Cobertura
Base: Backend (AUT-BE) Lógica interna de Django/DRF, reglas de negocio, serializers, permisos (401/403), métodos HTTP no permitidos (405) y persistencia en PostgreSQL de prueba. Django APITestCase + coverage.py 15 tests (mínimo exigido: 12)
Centro: API (AUT-API) Contrato HTTP de endpoints desde afuera (caja negra), códigos de estado, esquemas JSON, encadenamiento CRUD y escenarios negativos. Postman (v2.1) + Newman CLI 1 colección CRUD (módulos Clientes/Pedidos y Producción)
Cúspide: UI / E2E (AUT-E2E) Flujos críticos de usuario navegando en la SPA Angular (Login parametrizado, creación de pedidos y carga móvil de producción). Playwright + Page Object Model (POM) 3 flujos críticos
Transversal: Accesibilidad (ACC) Cumplimiento de WCAG 2.2 Nivel AA en las vistas principales (Login, Pedidos, Producción y Landing). axe-core + Lighthouse + Lector NVDA Auditoría en todas las pantallas principales

2. Guía de Ejecución y Prerrequisitos (Entorno de Trabajo)

Para garantizar la reproducibilidad técnica de la suite de pruebas, cualquier colaborador o evaluador puede ejecutar las pruebas siguiendo estas instrucciones:

Prerrequisitos

  • Python 3.10+ y entorno virtual configurado.
  • Node.js (v18+) y npm para la ejecución de Newman y Angular.
  • PostgreSQL de prueba: Base de datos aislada para testing (test_granja_db), nunca la base de desarrollo.
  • Variables de entorno configuradas (baseUrl = http://localhost:8000, DATABASE_URL).

Comandos de Consola por Capa

A. Backend (Django REST Framework + Cobertura)

# Activar entorno virtual y situarse en la carpeta backend/
cd backend

# Ejecutar la suite completa de tests de integración/unitarios
python manage.py test

# Medir cobertura de código con coverage.py
coverage run --source='.' manage.py test
coverage report
coverage html   # Genera reporte interactivo en htmlcov/index.html

B. API (Postman + Newman CLI)

# Instalación de Newman y reporter htmlextra (si no están instalados)
npm install -g newman newman-reporter-htmlextra

# Ejecución de la colección completa y generación de reportes HTML y JUnit
newman run tests/api/Granja_NV_API.json \
  -e tests/api/entorno.local.json \
  -r cli,htmlextra,junit \
  --reporter-htmlextra-export reportes/newman_report.html \
  --reporter-junit-export reportes/newman_junit.xml

C. End-to-End (Playwright + POM)

# Situarse en la raíz del proyecto
# Ejecutar tests E2E en segundo plano (headless)
pytest e2e/tests/

# Ejecutar visualizando el navegador (headed)
pytest e2e/tests/ --headed

# Ejecutar reteniendo traces y evidencias ante fallos
pytest e2e/tests/ --tracing=retain-on-failure

3. Matriz de Trazabilidad de Requisitos

Estructura de vinculación entre Historias de Usuario, Casos de Prueba, código automatizado y defectos:

Historia de Usuario (HU) Caso de Prueba (TC) Test Automatizado (Archivo::Nombre) Resultado Bug Asociado
US-01 (Autenticación) AS-01 backend/users/tests/test_auth.py::test_login_valido_admin, frontend/granjanv/src/app/features/auth/auth.spec.ts Pass -
US-01 (Autenticación) AS-02 backend/users/tests/test_auth.py::test_login_credenciales_invalidas, e2e/tests/auth.spec.js Pass -
US-03 (Producción) TC-01 backend/produccion/tests/test\_views.py::test\_recoleccion\_maples\_actualiza\_stock, tests/api/Granja\_NV\_API.json, backend/produccion/tests/e2e/test\_produccion\_mobile.py::test\_recoleccion\_mobile Pass -
US-03 (Producción) TC-02 backend/produccion/tests/test\_views.py::test\_validacion\_cantidades\_negativas\_y\_permisos\_denegados, tests/api/Granja_NV_API.json Pass -
US-03 (Producción) TC-03 backend/produccion/tests/test_views.py::test_registro_mortalidad_descuenta_censo_aves, tests/api/Granja\_NV\_API.json Pass -
US-05 (Finanzas/Compras) FI-01 backend/compras/tests.py::GastoAPITests::test_empleado_no_puede_crear_gasto, backend/test/api/Granja_NV_API_compras-finanzas.json::Empleado sin permisos (403), backend/test/api/Granja_NV_API_compras-finanzas.json::Sin autenticación (401) Pass -
US-05 (Finanzas/Compras) FI-02 backend/compras/tests.py::GastoAPITests::test_no_permite_crear_gasto_con_monto_negativo Pass -
US-05 (Finanzas/Compras) FI-03 backend/compras/tests.py::GastoAPITests::test_no_permite_crear_gasto_con_monto_negativo Pass -
US-05 (Finanzas/Compras) FI-05 backend/compras/tests.py::GastoAPITests::test_crear_gasto_como_administrador, backend/test/api/Granja_NV_API_compras-finanzas.json::Crear gasto (201), backend/test/api/Granja_NV_API_compras-finanzas.json::Consultar gastos (200), frontend/granjanv/e2e/finanzas.spec.ts::El administrador puede crear y visualizar un gasto Pass -
US-07 (Gestión y resportes ) GR-01 backend/reportes/tests/test_reportes.py::test_permisos_reporte_completo  Pass -
US-07 (Gestión y resportes ) GR-02 backend/reportes/tests/test_reportes.py::test_filtrado_reportes_por_fecha  Pass -
US-08 (Ventas/Pedidos) VP-01 backend/pedidos/tests.py::test_vp01_alta_rapida_cliente, backend/test/api/Granja_NV_API_pedidos.json::VP-01 Alta rápida de cliente, frontend/granjanv/e2e/ventas-pedidos.spec.ts::VP-01: Alta rápida de cliente desde formulario Pass -
US-08 (Ventas/Pedidos) VP-02 backend/pedidos/tests.py::test_vp02_creacion_pedido, backend/test/api/Granja_NV_API_pedidos.json::VP-02 Creación de pedido Pass -
US-08 (Ventas/Pedidos) VP-03 backend/pedidos/tests.py::test_vp03_actualizacion_estado_entregado, backend/test/api/Granja_NV_API_pedidos.json::VP-03 Actualización de estado Entregado, frontend/granjanv/e2e/ventas-pedidos.spec.ts::VP-03: Actualización de estado “Entregado” Pass -
US-08 (Ventas/Pedidos) VP-04 backend/pedidos/tests.py::test_vp04_actualizacion_estado_cobrado, backend/test/api/Granja_NV_API_pedidos.json::VP-04 Actualización de estado Cobrado, frontend/granjanv/e2e/ventas-pedidos.spec.ts::VP-04: Actualización de estado “Cobrado” con confirmación de cierre Pass -
US-08 (Ventas/Pedidos) VP-05 backend/pedidos/tests.py::test_vp05_filtrado_pedidos_rango_fechas, backend/test/api/Granja_NV_API_pedidos.json::VP-05 Visualización de pedidos por rango de fechas Pass -
US-08 (Ventas/Pedidos) VP-06 backend/pedidos/tests.py::test_vp06_editar_pedido_creado, backend/test/api/Granja_NV_API_pedidos.json::VP-06 Editar un pedido creado Pass -
US-08 (Ventas/Pedidos) VP-07 backend/pedidos/tests.py::test_vp07_pedido_sin_cantidad_invalido, backend/test/api/Granja_NV_API_pedidos.json::VP-07 Pedido sin cantidad (cero) Pass -
US-08 (Ventas/Pedidos) VP-08 backend/pedidos/tests.py::test_vp08_pedido_cliente_inexistente, backend/test/api/Granja_NV_API_pedidos.json::VP-08 Pedido con cliente inexistente Pass -
US-08 (Ventas/Pedidos) VP-09 backend/pedidos/tests.py::test_vp09_validacion_cantidades_invalidas, backend/test/api/Granja_NV_API_pedidos.json::VP-09 Validación de cantidades inválidas (Negativas) Pass -
US-10 (Landing Pública) LP-01 backend/test/api/Granja_NV_API_reportes.json::PD-06 Pruebas API Recetas Landing  Pass -
US-10 (Landing Pública) LP-04 checklist/accesibilidad::ACC-LP-04 (Lighthouse + NVDA manual)  Pass Issue #67 (Desestimado por Stakeholder)
US-10 (Landing Pública) LP-04 checklist/accesibilidad::ACC-LP-04 (Lighthouse + NVDA manual)  Pass -
US-10 (Persistencia) PD-06 backend/test/api/Granja_NV_API.json::PD-06 Consulta de recetas desde MongoDB  Pass -

4. Accesibilidad (WCAG 2.2 Nivel AA)

  • Estándar aplicado: Criterios de conformidad WCAG 2.2 Nivel AA sobre las pantallas principales (Login, Pedidos, Producción y Landing Page).
  • Herramientas de evaluación: @axe-core/playwright (meta: 0 violaciones critical/serious), Google Lighthouse (meta: $\ge 90$) y recorrido manual asistivo con lector de pantalla NVDA y teclado (Tab, Shift+Tab, Enter, Esc).
  • Informe de Accesibilidad: [Enlace al informe consolidado / En construcción]
  • Bugs de Accesibilidad reportados:

Nota: Estos son bugs de accesibilidad, no están asociados a casos de prueba de la planilla Test Case.

Informe consolidado de Auditoría de Accesibilidad

5. Artefactos y Documentación Viva

6. Matriz de Riesgos del Proceso de QA

Riesgo Probabilidad Impacto Estrategia de Mitigación
Tiempo limitado para ejecución total Alta Alto Priorización rigurosa de rutas críticas y flujos principales.
Errores de integración frontend-backend-DB Media Alto Pruebas continuas de integración temprana sobre endpoints y base de datos.
Retraso en entrega de funcionalidades Media Alto Reprogramación flexible de casos priorizando componentes listos.
Fallas de conexión o entornos cloud Media Medio Verificación previa de conectividad y reanudación protocolizada.
Cambios sobre módulos ya terminados Media Medio Baterías de pruebas de regresión focalizadas.

Clone this wiki locally