rckrdmrd 59f1e3badf Initial commit - erp-core

2026-01-04 06:12:07 -06:00

13 KiB

Raw Blame History

TEST PLAN - MGN-003: Catálogos Maestros

Módulo: MGN-003 - Catálogos Maestros Sprint: Sprint 5-6 (Semanas 9-12) Story Points: 29 SP User Stories: 8 US Fecha: 2025-11-24 QA Owner: TBD Estado: Draft

1. RESUMEN DEL MÓDULO

1.1 Descripción

El módulo MGN-003 Catálogos Maestros gestiona los datos maestros fundamentales del ERP: partners (clientes/proveedores/contactos), países, monedas, tasas de cambio, unidades de medida, categorías de productos y condiciones de pago.

Estos catálogos son la base de datos de referencia para todos los módulos transaccionales (ventas, compras, inventario, financiero).

1.2 Funcionalidades Principales

Gestión de Partners: CRUD de clientes, proveedores, contactos con múltiples direcciones
Países y Regiones: Gestión de países, estados, ciudades
Monedas: Gestión de monedas y tasas de cambio
Unidades de Medida: UoM con conversiones (kg, g, unidades, cajas, etc.)
Categorías de Productos: Árbol de categorías jerárquico
Condiciones de Pago: Payment terms con plazos y descuentos

1.3 Dependencias

Módulos requeridos:

MGN-001: Fundamentos
MGN-002: Empresas

Datos maestros necesarios:

Empresas creadas
Usuarios autenticados

2. ALCANCE DEL TESTING

2.1 En Alcance

✅ CRUD de partners (clientes, proveedores, contactos)
✅ Múltiples direcciones por partner
✅ Gestión de países, estados, ciudades
✅ Gestión de monedas
✅ Tasas de cambio con historización
✅ Conversión de monedas
✅ Gestión de UoM con factores de conversión
✅ Categorías de productos (árbol jerárquico)
✅ Condiciones de pago con plazos
✅ Validación de datos (email, tax ID, etc.)
✅ Tenant isolation de catálogos

2.2 Fuera de Alcance

❌ Importación masiva de partners (Fase 2)
❌ Integración con APIs de tasas de cambio externas (Fase 2)
❌ Geocoding de direcciones (Fase 2)

2.3 Assumptions

Datos base de países pre-cargados (seed)
Monedas principales pre-cargadas (USD, EUR, ARS, etc.)

3. ESTRATEGIA DE TESTING

3.1 Tipos de Tests

Unit Tests: 48 tests

Backend (32 tests):

PartnersService: 12 tests (CRUD, validaciones, direcciones)
CurrenciesService: 8 tests (CRUD, conversiones, tasas)
UoMService: 6 tests (CRUD, conversiones)
CategoriesService: 6 tests (árbol jerárquico)

Frontend (16 tests):

PartnerList component: 5 tests
PartnerForm component: 5 tests
CurrencyConverter component: 3 tests
CategoryTree component: 3 tests

Integration Tests: 24 tests

Partners API: 10 tests
- GET /api/v1/partners
- POST /api/v1/partners
- PUT /api/v1/partners/:id
- DELETE /api/v1/partners/:id
- POST /api/v1/partners/:id/addresses
Currencies API: 6 tests
- GET /api/v1/currencies
- GET /api/v1/currencies/convert
UoM API: 4 tests
- GET /api/v1/uom
- POST /api/v1/uom/convert
Categories API: 4 tests
- GET /api/v1/categories/tree
- POST /api/v1/categories

E2E Tests: 8 tests

Crear partner cliente con múltiples direcciones
Crear partner proveedor, convertir a cliente-proveedor
Configurar tasa de cambio, convertir montos
Crear árbol de categorías (Electrónica > Laptops > Gaming)
Crear UoM, configurar conversiones (1 caja = 12 unidades)
Buscar partner por nombre, email, tax ID
Tenant isolation: partners no visibles entre tenants
Validación de email y tax ID

4. TEST CASES

4.1 Casos de Prueba Funcionales

TC-MGN-003-001: Crear Partner Cliente con Direcciones

US: US-MGN-003-001-001 Prioridad: P0 Tipo: Functional Nivel: E2E

Precondiciones:

Usuario autenticado
Empresa activa

Pasos:

Navegar a /partners
Click en "Nuevo Partner"
Ingresar datos:
- Nombre: "Cliente ABC"
- Email: "contacto@abc.com"
- Tax ID: "20-12345678-9"
- Tipo: "Cliente"
Agregar dirección facturación:
- Calle: "Av. Siempre Viva 123"
- Ciudad: "Buenos Aires"
- País: "Argentina"
Agregar dirección entrega (diferente)
Click en "Guardar"

Resultado Esperado:

Partner se crea en partners table
2 direcciones se crean en partner_addresses
Partner aparece en lista con tipo "Cliente"
Email y tax ID son únicos en tenant

Criterios de Aceptación Validados:

AC-001: Admin puede crear partners
AC-002: Partner puede tener múltiples direcciones
AC-003: Email y tax ID son únicos por tenant

TC-MGN-003-002: Conversión de Moneda con Tasa Actual

US: US-MGN-003-003-002 Prioridad: P0 Tipo: Functional Nivel: Integration

Precondiciones:

Moneda USD existe
Moneda ARS existe
Tasa USD->ARS = 1000 (fecha actual)

Pasos:

POST /api/v1/currencies/convert con body:

{
  "amount": 100,
  "from": "USD",
  "to": "ARS",
  "date": "2025-11-24"
}

Resultado Esperado:

Status code: 200 OK
Response: { "converted_amount": 100000, "rate": 1000 }
Usa tasa más reciente <= fecha especificada

Criterios de Aceptación Validados:

AC-004: Sistema convierte entre monedas usando tasa actual
AC-005: Tasas son historizadas por fecha

TC-MGN-003-003: Conversión de UoM (Unidades de Medida)

US: US-MGN-003-004-001 Prioridad: P0 Tipo: Functional Nivel: Integration

Precondiciones:

UoM "Unidad" existe
UoM "Caja" existe con factor 12 (1 caja = 12 unidades)

Pasos:

POST /api/v1/uom/convert con body:

{
  "quantity": 5,
  "from_uom": "Caja",
  "to_uom": "Unidad"
}

Resultado Esperado:

Status code: 200 OK
Response: { "converted_quantity": 60 }
Cálculo: 5 cajas * 12 unidades/caja = 60 unidades

Criterios de Aceptación Validados:

AC-006: Sistema convierte entre UoM usando factores
AC-007: Conversiones son bidireccionales

TC-MGN-003-004: Árbol de Categorías Jerárquico

US: US-MGN-003-005-001 Prioridad: P0 Tipo: Functional Nivel: E2E

Precondiciones:

Usuario autenticado

Pasos:

Navegar a /categories
Crear categoría raíz: "Electrónica"
Crear subcategoría: "Electrónica > Laptops"
Crear subcategoría: "Electrónica > Laptops > Gaming"
GET /api/v1/categories/tree

Resultado Esperado:

Estructura de árbol se crea correctamente
GET tree retorna JSON jerárquico:

{
  "id": 1,
  "name": "Electrónica",
  "children": [{
    "id": 2,
    "name": "Laptops",
    "children": [{
      "id": 3,
      "name": "Gaming",
      "children": []
    }]
  }]
}

Criterios de Aceptación Validados:

AC-008: Categorías soportan jerarquía ilimitada
AC-009: GET tree retorna estructura completa

TC-MGN-003-005: Condiciones de Pago con Plazos

US: US-MGN-003-006-001 Prioridad: P0 Tipo: Functional Nivel: Integration

Precondiciones:

Usuario autenticado

Pasos:

POST /api/v1/payment-terms con body:

{
  "name": "30/60/90",
  "terms": [
    { "days": 30, "percentage": 33.33 },
    { "days": 60, "percentage": 33.33 },
    { "days": 90, "percentage": 33.34 }
  ]
}

Resultado Esperado:

Payment term se crea
Suma de percentages = 100%
Validación: percentages deben sumar 100%

Criterios de Aceptación Validados:

AC-010: Payment terms soportan múltiples plazos
AC-011: Percentages deben sumar 100%

TC-MGN-003-006: Búsqueda de Partner por Múltiples Criterios

US: US-MGN-003-001-001 Prioridad: P0 Tipo: Functional Nivel: Integration

Precondiciones:

100 partners creados

Pasos:

GET /api/v1/partners?search=ABC
GET /api/v1/partners?email=contacto@abc.com
GET /api/v1/partners?tax_id=20-12345678-9
GET /api/v1/partners?type=customer

Resultado Esperado:

Search busca en name, email, tax_id
Filtros se pueden combinar
Response incluye paginación
Performance <200ms con 10,000 partners

Criterios de Aceptación Validados:

AC-012: Búsqueda funciona por nombre, email, tax ID
AC-013: Filtros por tipo (customer, supplier, both)

TC-MGN-003-007: Tenant Isolation de Partners

US: US-MGN-003-001-001 Prioridad: P0 Tipo: Security Nivel: Integration

Precondiciones:

Tenant A tiene partner "Cliente A"
Tenant B tiene partner "Cliente B"

Pasos:

Login como usuario de Tenant A
GET /api/v1/partners
Verificar que solo retorna partners de Tenant A
Intentar GET /api/v1/partners/:id con partner de Tenant B

Resultado Esperado:

GET partners retorna solo partners de Tenant A
Intentar acceder partner de Tenant B resulta en 403
RLS policies previenen acceso cross-tenant

Criterios de Aceptación Validados:

AC-014: Partners están aislados por tenant

TC-MGN-003-008: Validación de Email y Tax ID Únicos

US: US-MGN-003-001-001 Prioridad: P0 Tipo: Functional Nivel: Integration

Precondiciones:

Partner "Cliente A" existe con email "cliente@a.com" y tax_id "20-11111111-1"

Pasos:

POST /api/v1/partners con email duplicado
POST /api/v1/partners con tax_id duplicado

Resultado Esperado:

Status code: 409 Conflict
Error: "Email ya está en uso en este tenant"
Error: "Tax ID ya está en uso en este tenant"
Validación es por tenant (mismo email puede existir en otro tenant)

Criterios de Aceptación Validados:

AC-015: Email y tax ID son únicos por tenant
AC-016: Errores de validación son claros

4.2 Casos de Prueba No Funcionales

TC-MGN-003-PERF-001: Performance de Búsqueda de Partners

Tipo: Performance Herramienta: k6

Escenario:

10,000 partners en BD
50 usuarios concurrentes
500 búsquedas/min
Duración: 3 minutos

Criterios de Éxito:

p50: <100ms
p95: <200ms
p99: <400ms
Índices optimizados (name, email, tax_id)

5. DATOS DE PRUEBA

5.1 Test Data Requirements

Partners (50):

25 clientes
20 proveedores
5 cliente-proveedor

Países (pre-cargados):

Argentina con estados y ciudades principales
Chile, Brasil, Uruguay

Monedas (pre-cargadas):

USD, EUR, ARS, CLP, BRL

Tasas de Cambio:

USD/ARS: 1000 (2025-11-24)
EUR/ARS: 1100 (2025-11-24)

UoM:

Unidad, Caja, Pallet
kg, g, ton
m, cm, mm

Categorías:

Electrónica > Laptops, Smartphones
Muebles > Oficina, Hogar

6. AMBIENTE DE TESTING

6.1 Configuración

Base de datos: PostgreSQL 16

Tables: partners, partner_addresses, currencies, currency_rates, uom, product_categories, payment_terms

Backend: NestJS

Port: 3000

Frontend: React

Port: 5173

6.2 URLs

API: http://localhost:3000/api/v1/partners
Frontend: http://localhost:5173/partners

7. SCHEDULE

7.1 Timeline

Sprint	RF	Actividad	Duración
Sprint 5	RF-001, RF-002	Partners, Países	2 sem
Sprint 4	RF-003	Monedas, Tasas de Cambio	2 sem
Sprint 6	RF-004, RF-005, RF-006	UoM, Categorías, Payment Terms	2 sem

8. ENTRY/EXIT CRITERIA

Entry Criteria

MGN-001 y MGN-002 completados
Empresas creadas
Test data preparado
Ambiente QA disponible

Exit Criteria

80 tests ejecutados (100%)
Unit coverage >80%
Integration tests pasando (100%)
E2E tests pasando (100%)
Bugs P0/P1 resueltos
Performance <200ms para búsquedas

9. DEFECT MANAGEMENT

9.1 Severidad de Bugs

P0 - Blocker:

Partners no se crean
Conversión de monedas incorrecta
SLA: 24 horas

P1 - Critical:

Búsqueda de partners no funciona
UoM conversions incorrectas
SLA: 3 días

10. RIESGOS ESPECÍFICOS DEL MÓDULO

Riesgo	Probabilidad	Impacto	Mitigación
Conversión de monedas incorrecta	Media	Alto	Unit tests exhaustivos. Validación con casos reales.
Performance con 100k partners	Alta	Medio	Índices optimizados. Paginación. Búsqueda full-text.
Árbol de categorías corrupto	Baja	Medio	Validación de parent_id. No permitir ciclos.

11. MÉTRICAS

11.1 Test Execution Metrics

Total test cases: 80

Unit: 48
Integration: 24
E2E: 8

Executed: 0/80 (0%) Pass rate: 0% (objetivo: >95%)

11.2 Coverage Metrics

Unit test coverage: 0% (objetivo: >80%) API coverage: 0/20 endpoints (objetivo: 100%)

12. SIGN-OFF

QA Engineer: _______________ Date: _______ Tech Lead: _______________ Date: _______ Product Owner: _______________ Date: _______

13. REFERENCIAS

Versión: 1.0 Última actualización: 2025-11-24 Estado: Draft

13 KiB Raw Blame History

TEST PLAN - MGN-003: Catálogos Maestros

1. RESUMEN DEL MÓDULO

1.1 Descripción

1.2 Funcionalidades Principales

1.3 Dependencias

2. ALCANCE DEL TESTING

2.1 En Alcance

2.2 Fuera de Alcance

2.3 Assumptions

3. ESTRATEGIA DE TESTING

3.1 Tipos de Tests

Unit Tests: 48 tests

Integration Tests: 24 tests

E2E Tests: 8 tests

4. TEST CASES

4.1 Casos de Prueba Funcionales

TC-MGN-003-001: Crear Partner Cliente con Direcciones

TC-MGN-003-002: Conversión de Moneda con Tasa Actual

TC-MGN-003-003: Conversión de UoM (Unidades de Medida)

TC-MGN-003-004: Árbol de Categorías Jerárquico

TC-MGN-003-005: Condiciones de Pago con Plazos

TC-MGN-003-006: Búsqueda de Partner por Múltiples Criterios

TC-MGN-003-007: Tenant Isolation de Partners

TC-MGN-003-008: Validación de Email y Tax ID Únicos

4.2 Casos de Prueba No Funcionales

TC-MGN-003-PERF-001: Performance de Búsqueda de Partners

5. DATOS DE PRUEBA

5.1 Test Data Requirements

6. AMBIENTE DE TESTING

6.1 Configuración

6.2 URLs

7. SCHEDULE

7.1 Timeline

8. ENTRY/EXIT CRITERIA

Entry Criteria

Exit Criteria

9. DEFECT MANAGEMENT

9.1 Severidad de Bugs

10. RIESGOS ESPECÍFICOS DEL MÓDULO

11. MÉTRICAS

11.1 Test Execution Metrics

11.2 Coverage Metrics

12. SIGN-OFF

13. REFERENCIAS

13 KiB

Raw Blame History