795 lines
29 KiB
Markdown
795 lines
29 KiB
Markdown
# 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
|