# 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:**
- admin@tenant-a.com (admin role)
- contador@tenant-a.com (accountant role)
- vendedor@tenant-a.com (sales role)
- viewer@tenant-a.com (viewer role)
- user@tenant-b.com (user role)

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

---

## 11. REFERENCIAS

**Documentación del Proyecto:**
- [ADR-010: Testing Strategy](../adr/ADR-010-testing-strategy.md)
- [User Stories](../03-user-stories/)
- [Requerimientos Funcionales](../02-modelado/requerimientos-funcionales/)
- [Especificaciones Técnicas Backend](../02-modelado/especificaciones-tecnicas/backend/)
- [Especificaciones Técnicas Frontend](../02-modelado/especificaciones-tecnicas/frontend/)
- [Matrices de Trazabilidad](../02-modelado/trazabilidad/)

**Test Plans por Módulo:**
- [TEST-PLAN-MGN-001: Fundamentos](./TEST-PLAN-MGN-001-fundamentos.md)
- [TEST-PLAN-MGN-002: Empresas](./TEST-PLAN-MGN-002-empresas.md)
- [TEST-PLAN-MGN-003: Catálogos](./TEST-PLAN-MGN-003-catalogos.md)
- [TEST-PLAN-MGN-004: Financiero](./TEST-PLAN-MGN-004-financiero.md)
- [TEST-PLAN-MGN-005: Inventario](./TEST-PLAN-MGN-005-inventario.md)
- [TEST-PLAN-MGN-006: Compras](./TEST-PLAN-MGN-006-compras.md)
- [TEST-PLAN-MGN-007: Ventas](./TEST-PLAN-MGN-007-ventas.md)
- [TEST-PLAN-MGN-008: Analítica](./TEST-PLAN-MGN-008-analitica.md)
- [TEST-PLAN-MGN-009: CRM](./TEST-PLAN-MGN-009-crm.md)
- [TEST-PLAN-MGN-010: RRHH](./TEST-PLAN-MGN-010-rrhh.md)
- [TEST-PLAN-MGN-011: Proyectos](./TEST-PLAN-MGN-011-proyectos.md)
- [TEST-PLAN-MGN-012: Reportes](./TEST-PLAN-MGN-012-reportes.md)
- [TEST-PLAN-MGN-013: Portal](./TEST-PLAN-MGN-013-portal.md)
- [TEST-PLAN-MGN-014: Mensajería](./TEST-PLAN-MGN-014-mensajeria.md)

**Referencias Externas:**
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [WCAG 2.1 Guidelines](https://www.w3.org/WAI/WCAG21/quickref/)
- [Testing Library Best Practices](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library)
- [Playwright Best Practices](https://playwright.dev/docs/best-practices)
- [Jest Best Practices](https://github.com/goldbergyoni/javascript-testing-best-practices)

---

## 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