rckrdmrd/erp-core
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
59f1e3badf
erp-core/docs/06-test-plans/MASTER-TEST-PLAN.md

29 KiB
Raw Blame History

MASTER TEST PLAN - ERP GENÉRICO

Proyecto: ERP Genérico Versión: 1.0 Fecha: 2025-11-24 QA Lead: TBD Estado: Draft

1. INTRODUCCIÓN

1.1 Propósito

Este documento define la estrategia completa de testing para el ERP Genérico, un sistema modular que servirá como base para 3 ERPs especializados (Construcción, Inmobiliaria y Genérico).

El propósito de este Master Test Plan es:

  • Establecer la estrategia global de calidad del proyecto
  • Definir tipos de testing, niveles y responsabilidades
  • Coordinar testing entre los 14 módulos del sistema
  • Asegurar cobertura completa: funcional, no funcional y especializada
  • Minimizar defectos en producción y maximizar ROI de QA

1.2 Alcance

Módulos en Alcance:

  • 14 módulos (MGN-001 a MGN-014)
  • 80 Requerimientos Funcionales
  • 147 User Stories
  • 93 tablas de base de datos
  • Arquitectura: NestJS + React + PostgreSQL + Multi-tenancy

Alcance del Testing:

  • Testing funcional (unit, integration, E2E)
  • Testing no funcional (performance, security, accessibility)
  • Testing especializado (multi-tenancy, RLS, data migration)
  • Regression testing automatizado
  • UAT (User Acceptance Testing)

Story Points y Duración:

  • Total Story Points: 673 SP
  • User Stories: 147 US
  • Velocidad estimada: 20 SP/sprint
  • Duración total: 34 sprints (68 semanas)

1.3 Objetivos de Calidad

Métricas de Cobertura:

  • Code coverage: >80% (backend y frontend)
  • API endpoint coverage: 100% (todos los endpoints testeados)
  • E2E coverage: 100% flujos críticos de negocio
  • Automated tests: >70% de tests automatizados

Métricas de Defectos:

  • Bug density: <1 bug/100 LOC (líneas de código)
  • Defect escape rate: <5% (bugs encontrados en producción)
  • MTTD (Mean Time to Detect): <1 día
  • MTTR (Mean Time to Resolve): <3 días para P0/P1

Métricas de Performance:

  • Response time: <300ms (p95) para endpoints API
  • Page load time: <2s (p95) para frontend
  • Throughput: >1000 req/s en peak load
  • Error rate: <1% en peak load

2. ESTRATEGIA DE TESTING

2.1 Testing Pyramid

El proyecto seguirá la estrategia de Testing Pyramid para optimizar velocidad, cobertura y costos:

        E2E Tests (10%)
       /              \
    Integration Tests (30%)
   /                        \
  Unit Tests (60%)

Distribución estimada de tests:

  • Unit tests: ~960 tests (60%) - Fast, isolated, developer-owned
  • Integration tests: ~480 tests (30%) - API + Component integration
  • E2E tests: ~160 tests (10%) - Critical user journeys
  • Total estimado: ~1,600 tests

Justificación:

  • Base amplia de unit tests garantiza lógica de negocio correcta
  • Integration tests validan contratos entre capas (API, DB, UI)
  • E2E tests validan flujos críticos desde perspectiva de usuario
  • Pirámide invertida sería lenta y costosa de mantener

2.2 Tipos de Testing

2.2.1 Testing Funcional

Unit Testing

  • Backend: Jest + NestJS testing utilities
  • Frontend: Vitest + React Testing Library
  • Objetivo: Testear lógica de negocio aislada (services, helpers, hooks)
  • Coverage: >80% statement coverage
  • Ejecución: Pre-commit hook (< 2 min)

Integration Testing

  • Backend: Supertest (API endpoints), TestContainers (DB real)
  • Frontend: React Testing Library (component + API integration)
  • Objetivo: Validar contratos entre capas
  • Coverage: 100% endpoints API, componentes principales
  • Ejecución: CI pipeline en PRs (< 10 min)

E2E Testing

  • Herramienta: Playwright (cross-browser)
  • Objetivo: Validar flujos de usuario end-to-end
  • Coverage: Flujos críticos de negocio (happy paths + error paths)
  • Ejecución: Nightly builds (< 30 min)

API Testing

  • Herramienta: Postman/Newman (contract testing)
  • Objetivo: Validar contratos OpenAPI, request/response schemas
  • Coverage: 100% endpoints documentados
  • Ejecución: CI pipeline en PRs

2.2.2 Testing No Funcional

Performance Testing

  • Herramienta: k6 (load testing)
  • Tipos: Load, Stress, Spike, Soak testing
  • Objetivo: Validar performance bajo carga
  • Criterios:
    • p50: <100ms
    • p95: <300ms
    • p99: <500ms
    • Throughput: >1000 req/s
  • Ejecución: Pre-release (staging), monitoring continuo

Security Testing

  • Herramientas: OWASP ZAP (DAST), Snyk (SAST, dependency scanning)
  • Tipos: OWASP Top 10, SQL injection, XSS, CSRF, JWT validation
  • Objetivo: Cero vulnerabilidades críticas en producción
  • Ejecución: CI pipeline + pre-release audit

Accessibility Testing

  • Herramienta: axe-core + manual testing
  • Estándar: WCAG 2.1 Level AA
  • Objetivo: Producto accesible para usuarios con discapacidades
  • Ejecución: CI pipeline + manual audit pre-release

Compatibility Testing

  • Browsers: Chrome, Firefox, Safari, Edge (últimas 2 versiones)
  • Devices: Desktop, Tablet, Mobile (responsive)
  • Herramienta: BrowserStack (cloud testing)
  • Ejecución: Pre-release (QA environment)

2.2.3 Testing Especializado

Multi-tenancy Testing

  • Objetivo: Validar aislamiento entre tenants (schema isolation + RLS)
  • Test cases:
    • Tenant A no puede ver datos de Tenant B
    • Usuario sin acceso a tenant recibe 403
    • Queries con filtro tenant_id son aplicados automáticamente
  • Ejecución: Integration tests + E2E tests

RLS (Row Level Security) Testing

  • Objetivo: Validar políticas de seguridad a nivel de fila en PostgreSQL
  • Test cases:
    • RLS policies aplicadas correctamente según rol
    • Bypass de RLS solo para service role
    • Políticas de SELECT, INSERT, UPDATE, DELETE independientes
  • Ejecución: Integration tests con DB real

Data Migration Testing

  • Objetivo: Validar migraciones de BD sin pérdida de datos
  • Test cases:
    • Migraciones up/down ejecutan correctamente
    • Datos existentes no se corrompen
    • Performance de migraciones en DB grande
  • Ejecución: Manual + automated (staging con prod clone)

Backup/Recovery Testing

  • Objetivo: Validar recuperación ante desastres
  • Test cases:
    • Backup completo restaura 100% de datos
    • RTO (Recovery Time Objective) < 4 horas
    • RPO (Recovery Point Objective) < 1 hora
  • Ejecución: Mensual (disaster recovery drill)

2.3 Niveles de Testing

L0: Unit Testing (Developers)

  • Responsable: Developer que implementa la funcionalidad
  • Herramientas: Jest, Vitest
  • Coverage objetivo: >80% per module
  • Ejecución: Pre-commit hook (Husky)
  • Duración: <2 min
  • Criterio de éxito: Todos los tests pasando, coverage >80%

L1: Integration Testing (Developers + QA)

  • Responsable: Developer que completa US
  • Herramientas: Supertest, React Testing Library, TestContainers
  • Coverage objetivo: Todos los endpoints API, componentes principales
  • Ejecución: CI pipeline (GitHub Actions en PR)
  • Duración: <10 min
  • Criterio de éxito: Todos los tests pasando, contratos validados

L2: E2E Testing (QA)

  • Responsable: QA Engineer
  • Herramientas: Playwright (headless + headed)
  • Coverage objetivo: Flujos críticos de negocio
  • Ejecución: Nightly builds + on-demand
  • Duración: <30 min
  • Criterio de éxito: 100% flujos críticos pasando

L3: Acceptance Testing (Product Owner + QA)

  • Responsable: PO + QA Lead
  • Herramientas: Manual testing + exploratory testing
  • Coverage objetivo: Criterios de aceptación de US
  • Ejecución: Sprint review
  • Duración: Variable (depende de US)
  • Criterio de éxito: PO valida que US cumple criterios de aceptación

3. AMBIENTE DE TESTING

3.1 Ambientes

Ambiente Propósito Deploy Data Base URL
Development Dev local Manual Fixtures http://localhost:3000
CI/CD Tests automáticos Auto (PR) Seeded -
QA Testing manual Auto (develop) Anonymized prod https://qa.erp.local
Staging Pre-producción Manual Prod clone https://staging.erp.com
Production Producción Manual Real https://erp.com

3.2 Datos de Prueba

Fixtures (Development)

Propósito: Desarrollo local, unit tests, integration tests

Tenants:

  • tenant-a (activo, plan Pro)
  • tenant-b (activo, plan Enterprise)
  • tenant-c (inactivo, plan Trial)

Usuarios:

Datos maestros:

  • 100 productos (10 por categoría)
  • 50 partners (25 clientes, 20 proveedores, 5 ambos)
  • 10 almacenes (5 en tenant-a, 5 en tenant-b)
  • Catálogos: países, monedas, UoM, payment terms

Transacciones:

  • 50 órdenes de venta (estados variados)
  • 30 órdenes de compra (estados variados)
  • 100 movimientos de stock
  • 50 facturas (cliente + proveedor)

Seeded Data (CI/CD)

Propósito: Tests automáticos en CI pipeline

Características:

  • 2 tenants mínimos (tenant-test-a, tenant-test-b)
  • Usuarios básicos (admin, user, guest) por tenant
  • Catálogos mínimos (10 productos, 10 partners, 2 almacenes)
  • Reset automático antes de cada test suite
  • Performance optimizada (datos mínimos necesarios)

Anonymized Data (QA)

Propósito: Testing manual en ambiente QA

Características:

  • Copia de producción anonymizada (GDPR compliant)
  • Datos de producción reales pero scrambled:
    • Nombres: "Juan Pérez" -> "User 12345"
    • Emails: "juan@acme.com" -> "user12345@example.com"
    • Teléfonos: aleatorios
    • Direcciones: aleatorias
  • Estructura y volumen idénticos a producción
  • Refresh semanal (viernes noche)
  • Auditoría de acceso (quien, cuando, que consultó)

Prod Clone (Staging)

Propósito: Pre-release testing, performance testing

Características:

  • Snapshot de producción (full clone)
  • Datos reales pero acceso restringido
  • Refresh mensual
  • Usado para:
    • Performance testing (k6 load tests)
    • Data migration testing
    • Pre-release validation

4. TEST CASES POR MÓDULO

Resumen de Coverage

Módulo Nombre US Unit Integration E2E Total Tests Prioridad
MGN-001 Fundamentos 16 96 48 16 160 P0
MGN-002 Empresas 7 42 21 7 70 P0
MGN-003 Catálogos 8 48 24 8 80 P0
MGN-004 Financiero 18 108 54 18 180 P0
MGN-005 Inventario 14 84 42 14 140 P0
MGN-006 Compras 12 72 36 12 120 P0/P1
MGN-007 Ventas 12 72 36 12 120 P0
MGN-008 Analítica 10 60 30 10 100 P0
MGN-009 CRM 8 48 24 8 80 P1
MGN-010 RRHH 7 42 21 7 70 P1
MGN-011 Proyectos 10 60 30 10 100 P1
MGN-012 Reportes 6 36 18 6 60 P1
MGN-013 Portal 6 36 18 6 60 P1
MGN-014 Mensajería 12 72 36 12 120 P0
TOTAL 14 módulos 147 876 438 147 1,461 -

Distribución por Tipo

Unit Tests (876 tests - 60%):

  • Services: 40% (350 tests)
  • Controllers: 20% (175 tests)
  • Helpers/Utils: 15% (131 tests)
  • Components: 15% (131 tests)
  • Hooks: 10% (89 tests)

Integration Tests (438 tests - 30%):

  • API endpoints: 60% (263 tests)
  • Database transactions: 20% (88 tests)
  • Component + API: 15% (66 tests)
  • State management: 5% (21 tests)

E2E Tests (147 tests - 10%):

  • Happy paths: 60% (88 tests)
  • Error paths: 25% (37 tests)
  • Edge cases: 15% (22 tests)

5. SCHEDULE DE TESTING

Por Sprint (2 semanas)

Semana 1: Development Week

  • Día 1-3: Development + Unit tests (developers escriben código + tests)
  • Día 4: Code review + Integration tests (peer review)
  • Día 5: Bug fixing inicial

Semana 2: Testing Week

  • Día 6-7: QA testing + E2E tests (QA ejecuta test plan)
  • Día 8: Bug fixing (developers resuelven bugs P0/P1)
  • Día 9: Regression testing (QA re-testea fixes + smoke tests)
  • Día 10: Sprint review + retrospective (demo + lecciones aprendidas)

Hitos de Testing

Sprint Módulo Milestone Tests Acumulados Fecha Estimada
1-4 MGN-001 Auth & Users completo 160 tests Semana 8
5-6 MGN-002-003 Catálogos completos 310 tests Semana 12
7-11 MGN-004 Financiero completo 490 tests Semana 22
12-15 MGN-005 Inventario completo 630 tests Semana 30
16-18 MGN-006 Compras completo 750 tests Semana 36
19-21 MGN-007 Ventas completo 870 tests Semana 42
22-23 MGN-008 Analítica completo 970 tests Semana 46
24-25 MGN-009 CRM completo 1,050 tests Semana 50
26-27 MGN-010 RRHH completo 1,120 tests Semana 54
28-29 MGN-011 Proyectos completo 1,220 tests Semana 58
30-31 MGN-012 Reportes completo 1,280 tests Semana 62
32 MGN-013 Portal completo 1,340 tests Semana 64
33-34 MGN-014 Mensajería completo 1,461 tests Semana 68

Releases

MVP Release (Sprint 23 - Semana 46):

  • Módulos P0 completos: MGN-001 a MGN-008 + MGN-014
  • 970 tests pasando
  • Performance testing aprobado
  • Security audit aprobado
  • UAT completado

Post-MVP Release (Sprint 34 - Semana 68):

  • Todos los módulos completos
  • 1,461 tests pasando
  • Coverage >80%
  • Zero P0/P1 bugs abiertos

6. CRITERIOS DE ENTRADA/SALIDA

Entry Criteria (Sprint)

Criterios que deben cumplirse antes de iniciar testing en un sprint:

  • User Stories definidas y estimadas (DoR cumplido)
  • Criterios de aceptación escritos en formato Gherkin
  • Test cases escritos en Test Plan del módulo
  • Ambiente de QA disponible y funcional
  • Test data preparado (fixtures + seeded data)
  • Código implementado y mergeado a develop
  • Unit tests escritos y pasando (>80% coverage)
  • Integration tests escritos y pasando
  • Code review completado

Exit Criteria (Sprint)

Criterios que deben cumplirse para considerar sprint completado:

  • Todas las US del sprint completas (DoD cumplido)
  • Unit tests >80% coverage por módulo
  • Integration tests 100% pasando
  • E2E tests críticos 100% pasando
  • Bugs P0/P1 resueltos (100%)
  • Bugs P2 documentados en backlog
  • Code review aprobado por Tech Lead
  • Documentación actualizada (Swagger, README)
  • Performance tests pasando (si aplica)
  • Security scan pasando (sin vulnerabilidades críticas)
  • Sprint review completado (PO acepta US)
  • Retrospective completada (lecciones aprendidas documentadas)

Definition of Ready (US)

Criterios para considerar una US "Ready for Development":

  • User story escrita en formato "Como [rol], Quiero [acción], Para [beneficio]"
  • Criterios de aceptación escritos en formato Gherkin
  • Reglas de negocio documentadas
  • Tareas técnicas desglosadas (backend, frontend, database)
  • Story points estimados (poker planning)
  • Sprint asignado según dependencias
  • Mockups/wireframes disponibles (si aplica)
  • Dependencias identificadas y resueltas
  • Test data requirements documentados
  • PO ha revisado y aprobado la US

Definition of Done (US)

Criterios para considerar una US "Completada":

  • Código implementado según Especificación Técnica
  • Unit tests escritos y pasando (>80% coverage)
  • Integration tests escritos y pasando
  • E2E test escrito (si aplica a flujo crítico)
  • Code review completado y aprobado
  • QA manual ejecutado según Test Plan
  • Bugs encontrados en QA resueltos
  • Criterios de aceptación validados por PO
  • Documentación actualizada (Swagger, README, CHANGELOG)
  • Merge a develop completado
  • CI pipeline pasando (sin errores)
  • Security scan pasando (sin vulnerabilidades)
  • Demo realizada en Sprint Review

7. HERRAMIENTAS

7.1 Testing Frameworks

Backend Testing:

  • Jest: Unit tests, integration tests
  • Supertest: API endpoint testing
  • TestContainers: Database integration tests con PostgreSQL real
  • ts-mockito: Mocking de dependencias
  • faker: Generación de test data

Frontend Testing:

  • Vitest: Unit tests (más rápido que Jest)
  • React Testing Library: Component testing
  • Playwright: E2E testing (cross-browser)
  • MSW (Mock Service Worker): API mocking
  • @testing-library/user-event: Simulación de interacciones de usuario

API Testing:

  • Postman: Manual API testing, colecciones de tests
  • Newman: Automated Postman tests en CI
  • OpenAPI Validator: Contract testing contra spec OpenAPI

Performance Testing:

  • k6: Load testing, stress testing
  • Lighthouse CI: Frontend performance monitoring
  • PostgreSQL EXPLAIN ANALYZE: Query performance profiling

Security Testing:

  • OWASP ZAP: DAST (Dynamic Application Security Testing)
  • Snyk: SAST + dependency vulnerability scanning
  • npm audit: Dependency security check
  • PostgreSQL pg_audit: Database audit logging

7.2 CI/CD

Pipeline: GitHub Actions

Stages:

  1. Build: Compile TypeScript (backend + frontend)
  2. Lint: ESLint + Prettier
  3. Unit Tests: Jest + Vitest (<2 min)
  4. Integration Tests: Supertest + RTL (<10 min)
  5. Security Scan: Snyk + npm audit
  6. Code Coverage: Codecov upload
  7. Quality Gate: SonarQube (coverage >80%, no critical bugs)
  8. E2E Tests: Playwright nightly builds
  9. Deploy: Auto deploy a QA (si todos los checks pasan)

Quality Gates (SonarQube):

  • Coverage: >80% (bloqueante)
  • Duplicated code: <3%
  • Code smells: <10 per 1000 LOC
  • Bugs: 0 critical, 0 major
  • Vulnerabilities: 0 critical, 0 major
  • Security hotspots: Review required

Code Coverage (Codecov):

  • Reporte en cada PR con diff coverage
  • Badge en README con coverage %
  • Bloqueo de PR si coverage disminuye >2%

7.3 Test Management

Test Cases: TestRail (opcional) o GitHub Issues con labels

  • Label: test-case
  • Label: priority:P0, priority:P1, priority:P2
  • Label: module:MGN-001, etc.

Bug Tracking: Jira

  • Proyecto: ERP-GEN
  • Issue Types: Bug, Test, Sub-task
  • Workflow: New -> In Progress -> Review -> Resolved -> Closed
  • Custom fields: Severity, Found in Sprint, Module

Test Data Management:

  • Faker.js: Generación de datos fake realistas
  • Factory pattern: Builders para crear objetos de test
  • Fixtures: JSON files en test/fixtures/
  • Seeding scripts: npm run seed:test

8. RIESGOS Y MITIGACIONES

Riesgo Probabilidad Impacto Severidad Mitigación
RLS no aísla tenants Media Crítico ALTA Tests dedicados de tenant isolation en cada módulo. Audit manual de RLS policies.
Performance degradation con escala Alta Alto ALTA Load testing desde Sprint 1. Profiling de queries lentas con EXPLAIN ANALYZE. Índices optimizados.
Data migration issues en producción Media Alto ALTA Migration tests con prod clone. Rollback plan documentado. Blue-green deployment.
Security vulnerabilities (OWASP Top 10) Media Crítico ALTA OWASP ZAP en CI pipeline. Security audit pre-release. Penetration testing externo.
Multi-browser compatibility issues Baja Medio MEDIA BrowserStack testing pre-release. Progressive enhancement approach. Polyfills para features nuevos.
Test suite demasiado lenta Alta Medio MEDIA Parallelización de tests. Test categorization (smoke, regression). Optimización de fixtures.
Flaky E2E tests Alta Medio MEDIA Playwright auto-wait. Retry logic (max 2 retries). Debugging traces en failures. Evitar sleeps hardcoded.
Insuficiente test data en QA Media Medio MEDIA Anonymization automática de prod data. Refresh semanal. Monitoring de data freshness.
Coverage artificialmente alto Media Alto ALTA Code review de tests. Mutation testing (Stryker.js). Coverage de branches, no solo statements.
Technical debt en tests Alta Medio MEDIA Refactor continuo. Test code review igual que prod code. DRY principle en test utilities.

Mitigaciones Proactivas

Tenant Isolation:

  • Test suite dedicada: tenant-isolation.spec.ts
  • Test cases: Crear registro en tenant A, intentar acceder desde tenant B, verificar 403
  • Ejecutar en cada módulo que toque datos multi-tenant
  • Manual audit de RLS policies por DBA antes de producción

Performance:

  • Load testing con k6 desde Sprint 1 (baseline)
  • Métricas de performance en dashboard (Grafana + Prometheus)
  • Alertas si p95 >300ms o throughput <1000 req/s
  • Profiling mensual de queries top 10 más lentas

Security:

  • OWASP ZAP scan en CI pipeline (bloqueante si crítico)
  • Snyk scan de dependencias (bloqueante si crítico)
  • Penetration testing externo pre-MVP release
  • Security champion en equipo (training OWASP Top 10)

9. MÉTRICAS Y REPORTES

9.1 Métricas de Calidad (KPIs)

Code Coverage:

  • Objetivo: >80% (backend y frontend)
  • Actual: Track en Codecov
  • Reporte: Badge en README + dashboard semanal
  • Alert: Si coverage disminuye >2% en PR

Test Pass Rate:

  • Objetivo: >95%
  • Actual: Track en CI pipeline (GitHub Actions)
  • Reporte: Dashboard en Grafana
  • Alert: Si pass rate <90% en 2 sprints consecutivos

Bug Density:

  • Objetivo: <1 bug/100 LOC
  • Actual: Total bugs / Total LOC * 100
  • Reporte: Informe mensual de QA
  • Alert: Si bug density >2 bugs/100 LOC

Defect Escape Rate:

  • Objetivo: <5%
  • Actual: Bugs en prod / Total bugs * 100
  • Reporte: Informe trimestral
  • Alert: Si defect escape rate >10%

MTTD (Mean Time to Detect):

  • Objetivo: <1 día
  • Actual: Promedio de tiempo entre introducción de bug y detección
  • Reporte: Informe mensual
  • Alert: Si MTTD >3 días

MTTR (Mean Time to Resolve):

  • Objetivo: <3 días para P0/P1
  • Actual: Promedio de tiempo entre detección y resolución
  • Reporte: Informe mensual
  • Alert: Si MTTR >5 días para P0

Automated Test Coverage:

  • Objetivo: >70% de tests automatizados
  • Actual: Automated tests / Total tests * 100
  • Reporte: Informe trimestral
  • Alert: Si coverage automatizado <60%

9.2 Métricas de Performance

Response Time (API):

  • Objetivo: p95 <300ms
  • Actual: Track con k6 load tests
  • Reporte: Dashboard en Grafana (real-time)
  • Alert: Si p95 >500ms

Page Load Time (Frontend):

  • Objetivo: p95 <2s
  • Actual: Track con Lighthouse CI
  • Reporte: Dashboard en Grafana
  • Alert: Si p95 >3s

Throughput:

  • Objetivo: >1000 req/s en peak load
  • Actual: Track con k6 load tests
  • Reporte: Informe mensual
  • Alert: Si throughput <500 req/s

Error Rate:

  • Objetivo: <1% en peak load
  • Actual: Track con APM (Application Performance Monitoring)
  • Reporte: Dashboard en Grafana (real-time)
  • Alert: Si error rate >5%

9.3 Reportes

Daily Test Execution Report (Automated):

  • Enviado por email a QA team + Tech Lead
  • Contenido:
    • Total tests ejecutados
    • Pass rate
    • Failed tests (con links a logs)
    • Flaky tests (tests que fallan intermitentemente)
    • Duración de test suite

Weekly Quality Dashboard:

  • Dashboard en Grafana (visible 24/7)
  • Contenido:
    • Code coverage trend (línea de tiempo)
    • Bug count por severidad (P0, P1, P2, P3)
    • Bug count por módulo
    • Velocity (SP completados por sprint)
    • Defect density trend
    • MTTD / MTTR trend

Sprint Test Summary Report:

  • Presentado en Sprint Review
  • Contenido:
    • US completadas vs planificadas
    • Total tests escritos en el sprint
    • Bugs encontrados y resueltos
    • Coverage alcanzado
    • Bloqueadores y riesgos
    • Lecciones aprendidas

Release Go/No-Go Decision Report:

  • Documento formal pre-release
  • Contenido:
    • Checklist de exit criteria (100% completado)
    • Resumen de testing ejecutado
    • Bugs abiertos por severidad
    • Performance test results
    • Security audit results
    • Recomendación: GO / NO-GO
  • Firmado por: QA Lead, Tech Lead, Product Owner

10. ROLES Y RESPONSABILIDADES

Rol Responsabilidades
QA Lead - Definir estrategia de testing global
- Crear Master Test Plan
- Coordinar testing entre módulos
- Aprobar exit criteria de releases
- Reportar métricas de calidad
- Gestionar equipo de QA
QA Engineer - Crear test cases por módulo
- Ejecutar testing manual
- Escribir E2E tests (Playwright)
- Reportar bugs en Jira
- Ejecutar regression testing
- Participar en UAT con PO
Developer (Backend) - Escribir unit tests (Jest)
- Escribir integration tests (Supertest)
- Code review de tests de pares
- Resolver bugs P0/P1
- Documentar APIs en Swagger
- Optimizar queries lentas
Developer (Frontend) - Escribir unit tests (Vitest)
- Escribir component tests (RTL)
- Code review de tests de pares
- Resolver bugs P0/P1
- Optimizar performance frontend
- Implementar accessibility
Tech Lead - Code review de PRs
- Aprobar architecture decisions
- Configurar quality gates
- Monitorear code coverage
- Resolver bloqueadores técnicos
- Mentorear equipo en best practices
Product Owner - Definir criterios de aceptación
- Participar en UAT (Sprint Review)
- Aprobar US como "Done"
- Priorizar bugs en backlog
- Decidir Go/No-Go en releases
- Representar stakeholders
DevOps Engineer - Configurar CI/CD pipeline
- Mantener ambientes (QA, Staging, Prod)
- Configurar monitoring (Grafana, Prometheus)
- Automatizar deployment
- Gestionar secrets y credentials
- Backup/recovery procedures
DBA - Revisar schemas y migraciones
- Optimizar queries lentas
- Configurar índices
- Auditar RLS policies
- Backup/recovery testing
- Performance tuning de PostgreSQL
Security Specialist - Ejecutar security audits
- Configurar OWASP ZAP scans
- Revisar vulnerabilidades (Snyk)
- Penetration testing pre-release
- Security training para equipo
- Incident response plan

11. REFERENCIAS

Documentación del Proyecto:

Test Plans por Módulo:

Referencias Externas:

12. APROBACIONES

12.1 Documento Revisado y Aprobado por:

QA Lead: Nombre: _______________ Firma: _______________ Fecha: _______________

Tech Lead: Nombre: _______________ Firma: _______________ Fecha: _______________

Product Owner: Nombre: _______________ Firma: _______________ Fecha: _______________

DevOps Lead: Nombre: _______________ Firma: _______________ Fecha: _______________

12.2 Control de Cambios

Versión Fecha Autor Cambios
1.0 2025-11-24 QA Architect Versión inicial

Fin del Master Test Plan

Documento: MASTER-TEST-PLAN.md Versión: 1.0 Fecha de Creación: 2025-11-24 Última Actualización: 2025-11-24 Estado: Draft - Pendiente de aprobación Próxima Revisión: Sprint 1 Retrospective