Una Test Design Specification (TDS) define cómo se realizarán las pruebas para características específicas. Mientras un plan de pruebas proporciona estrategia de alto nivel, el TDS profundiza en técnicas, criterios de cobertura, requisitos de datos y necesidades ambientales. Sirve como blueprint que guía la creación y ejecución de casos de prueba.

Propósito y Alcance

Por qué Importan las Especificaciones de Diseño de Pruebas

  • Planificación Detallada: Traduce estrategia en enfoques de prueba accionables
  • Aseguramiento de Cobertura: Garantiza pruebas comprehensivas en todas dimensiones
  • Reutilizabilidad: Proporciona plantillas para características similares
  • Transferencia de Conocimiento: Captura experiencia de pruebas
  • Trazabilidad: Vincula requisitos a técnicas de prueba a casos de prueba

Estructura IEEE 829 para TDS

1. Identificador de Especificación de Diseño de Prueba

ID de Documento: TDS-ECOMM-PAYMENT-v1.2
Característica: Módulo de Procesamiento de Pagos
Versión: 3.5.0
Autor: Ingeniero QA Senior - Alex Martinez
Fecha: 2024-10-06
Estado de Revisión: Aprobado

2. Características a Probar

## Características Bajo Prueba

### En Alcance
✅ Procesamiento de pago con tarjeta de crédito (Visa, MasterCard, Amex, Discover)
✅ Métodos de pago alternativos (PayPal, Apple Pay, Google Pay)
✅ Validación de pago y manejo de errores
✅ Flujo de autorización y captura de transacción
✅ Operaciones de reembolso y anulación
✅ Validación de cumplimiento PCI DSS
✅ Lógica de reintento de pago para fallos
✅ Soporte multi-moneda (USD, EUR, GBP, JPY)

### Fuera de Alcance
❌ Lógica de selección de proveedor de pasarela de pago
❌ Integración del sistema contable
❌ Generación de facturas

3. Refinamientos del Enfoque

## Enfoque de Prueba por Característica

### 3.1 Procesamiento de Tarjeta de Crédito

**Técnica de Prueba**: Partición de Equivalencia + Análisis de Valor Límite

**Clases de Equivalencia**:
- Números de tarjeta válidos (según algoritmo Luhn)
- Números de tarjeta inválidos (fallo checksum)
- Tarjetas vencidas (pasado, mes actual, futuro)
- Tipos de tarjeta (Visa, MC, Amex, Discover, no soportado)
- Validación CVV (3 dígitos, 4 dígitos, faltante, inválido)

**Valores Límite**:
- Vencimiento de tarjeta: Mes actual, próximo mes, 5 años futuro
- Montos de transacción: $0.01, $0.99, $1.00, $999.99, $1,000.00, $9,999.99
- CVV: 000, 001, 999, 1000 (para Amex)

**Requisitos de Datos de Prueba**:
- Números de tarjeta de crédito de sandbox de pasarela de pago
- Montos de casos extremos
- Varias marcas de tarjetas y países emisores

**Necesidades Ambientales**:
- Entorno sandbox de pasarela de pago
- Certificados SSL/TLS para transmisión segura
- Herramientas de throttling de red para prueba de timeout

### 3.2 Flujo de Autorización de Pago

**Técnica de Prueba**: Prueba de Transición de Estado

**Estados**:
1. INICIADO → Solicitud de pago creada
2. VALIDANDO → Validación de entrada en progreso
3. AUTORIZANDO → Enviado a pasarela de pago
4. AUTORIZADO → Pasarela aprobó
5. CAPTURANDO → Captura de fondos solicitada
6. CAPTURADO → Pago completo
7. FALLIDO → Fallo en cualquier etapa
8. CANCELADO → Cancelación iniciada por usuario

**Transiciones Válidas**:
- INICIADO → VALIDANDO → AUTORIZANDO → AUTORIZADO → CAPTURANDO → CAPTURADO
- Cualquier estado → FALLIDO (en error)
- INICIADO/VALIDANDO → CANCELADO

**Casos de Prueba Cubren**:
- Camino feliz: INICIADO → CAPTURADO
- Fallo de validación: INICIADO → VALIDANDO → FALLIDO
- Rechazo de pasarela: AUTORIZANDO → FALLIDO
- Timeout de red: AUTORIZANDO → (timeout) → FALLIDO
- Cancelación de usuario: VALIDANDO → CANCELADO

### 3.3 Manejo de Errores y Recuperación

**Técnica de Prueba**: Error Guessing + Pruebas Negativas

**Escenarios de Error**:
- Fallos de red (timeout, conexión rechazada, fallo DNS)
- Errores de pasarela (códigos HTTP 500, 502, 503, 504)
- Respuestas inválidas (JSON mal formado, campos requeridos faltantes)
- Rate limiting (429 Too Many Requests)
- Rechazo por fondos insuficientes
- Disparadores de detección de fraude

**Comportamiento Esperado del Sistema**:
- Mensajes de error claros al usuario
- Sin datos sensibles en logs de error
- Reintento automático con backoff exponencial
- Degradación elegante
- Protección de idempotencia

### 3.4 Pruebas de Seguridad

**Técnica de Prueba**: Guía OWASP + Requisitos PCI DSS

**Pruebas de Seguridad**:
- **Encriptación de Datos**: Verificar datos de tarjeta encriptados en tránsito (TLS 1.2+) y en reposo
- **Cumplimiento PCI DSS**: Datos de tarjeta nunca registrados, tokenización usada
- **Inyección SQL**: Probar formularios con payloads de inyección SQL
- **Prevención XSS**: Probar con payloads XSS
- **Protección CSRF**: Verificar tokens anti-CSRF
- **Gestión de Sesión**: Probar timeout de sesión
- **Control de Acceso**: Verificar solo usuarios autorizados pueden iniciar pagos

**Herramientas**:
- OWASP ZAP para escaneo automatizado
- Burp Suite para pruebas de penetración manual
- SSL Labs para validación de configuración TLS

### 3.5 Pruebas de Rendimiento

**Técnica de Prueba**: Load Testing + Stress Testing

**Criterios de Rendimiento**:
| Métrica | Objetivo | Método de Medición |
|---------|----------|-------------------|
| Tiempo de Respuesta (percentil 95) | <3 segundos | JMeter, New Relic |
| Throughput | 500 transacciones/minuto | Resultados load testing |
| Tasa de Error bajo carga | <0.1% | JMeter aggregate report |

**Escenarios de Carga**:
- Carga normal: 100 usuarios concurrentes
- Carga pico: 500 usuarios concurrentes (simulación Black Friday)
- Prueba de estrés: Ramp-up gradual hasta punto de quiebre

### 3.6 Soporte Multi-Moneda

**Técnica de Prueba**: Prueba de Tabla de Decisión

**Factores de Decisión**:
- Ubicación de usuario (US, EU, UK, Japan)
- Moneda seleccionada (USD, EUR, GBP, JPY)
- País emisor de tarjeta
- Moneda de cuenta de comerciante

**Tabla de Decisión de Muestra**:

| # | Ubicación Usuario | Moneda | País Tarjeta | Conversión Aplicada | Moneda Pasada a Pasarela |
|---|------------------|--------|--------------|-------------------|-------------------------|
| 1 | US | USD | US | No | USD |
| 2 | US | EUR | US | Sí (USD→EUR) | EUR |
| 3 | EU | EUR | EU | No | EUR |
| 4 | EU | USD | EU | Sí (EUR→USD) | USD |

4. Identificación de Pruebas

## Mapeo de Casos de Prueba

| Técnica de Prueba | Casos de Prueba | Prioridad |
|------------------|----------------|-----------|
| Partición de Equivalencia | TC-PAY-001 a TC-PAY-025 | Alta |
| Análisis Valor Límite | TC-PAY-026 a TC-PAY-040 | Alta |
| Prueba Transición Estado | TC-PAY-041 a TC-PAY-065 | Crítica |
| Manejo de Errores | TC-PAY-066 a TC-PAY-090 | Alta |
| Pruebas de Seguridad | TC-PAY-091 a TC-PAY-120 | Crítica |
| Pruebas de Rendimiento | TC-PAY-121 a TC-PAY-135 | Media |
| Multi-Moneda | TC-PAY-136 a TC-PAY-160 | Media |

**Total Casos de Prueba**: 160
**Tiempo Estimado de Ejecución**: 24 horas (manual), 4 horas (automatizado)
**Objetivo de Automatización**: 70% (112 casos de prueba)

5. Criterios de Pase/Fallo de Característica

## Criterios de Pase/Fallo

### Criterios de Aceptación Funcional
**PASA** si:
- Todos los casos de prueba críticos y de alta prioridad pasan
- Cero defectos críticos o de alta severidad abiertos
- 95% de todos los casos de prueba pasan
- Todas las pruebas de seguridad pasan
- Todas las verificaciones de cumplimiento PCI DSS pasan

**FALLA** si:
- Cualquier caso de prueba crítico falla
- Cualquier vulnerabilidad de seguridad crítica o alta encontrada
- Validación de cumplimiento PCI DSS falla
- Tasa de pase <90%

### Criterios de Aceptación de Rendimiento
**PASA** si:
- Tiempo de respuesta percentil 95 <3 segundos
- Tasa de error <0.1% bajo carga normal
- Sistema maneja 500 transacciones concurrentes sin degradación

**FALLA** si:
- Tiempo de respuesta >5 segundos
- Tasa de error >1%
- Sistema se bloquea bajo carga

Especificación de Datos de Prueba

## Requisitos de Datos de Prueba

### Datos de Tarjeta de Crédito de Prueba

**Fuente**: Tarjetas de Prueba Sandbox de Pasarela de Pago

| Tipo de Tarjeta | Número de Prueba | CVV | Vencimiento | Resultado Esperado |
|----------------|-----------------|-----|-------------|-------------------|
| Visa | 4111111111111111 | 123 | 12/25 | Aprobado |
| Visa | 4000000000000002 | 123 | 12/25 | Rechazado |
| MasterCard | 5555555555554444 | 123 | 12/25 | Aprobado |
| Amex | 378282246310005 | 1234 | 12/25 | Aprobado |

Mejores Prácticas

1. Mantener TDS como Documento Vivo

Actualizar TDS conforme cambien requisitos:

  • Control de versiones en Git
  • Revisión trimestral o después de cambios importantes

2. Involucrar Stakeholders en Revisión

Revisión de TDS debe incluir:

  • Equipo QA (completitud del enfoque)
  • Desarrolladores (factibilidad técnica)
  • Product owners (cobertura de negocio)
  • Equipo de seguridad (validación de cumplimiento)

3. Balancear Detalle y Mantenibilidad

Muy Poco Detalle: “Probar procesamiento de pagos” ❌ Demasiado Detalle: Pasos individuales para 160 casos de prueba ❌ Justo: Técnicas de prueba, clases de datos, criterios de aceptación ✅

Conclusión

Una Test Design Specification bien elaborada cierra la brecha entre estrategia de alto nivel y ejecución detallada de casos de prueba. Al definir técnicas, criterios de cobertura, requisitos de datos y umbrales de pase/fallo, TDS asegura pruebas sistemáticas, comprehensivas y repetibles.