Una Test Design Specification (TDS) es la capa faltante entre la estrategia de pruebas y la ejecución que la mayoría de equipos pasa por alto — y por la que la mayoría paga en defectos escapados. Según la encuesta ISTQB Advanced Level Agile Technical Tester 2024, los equipos con TDS documentadas encuentran un 34% más de defectos en características de alta complejidad que los equipos que trabajan directamente del plan a los casos de prueba. La investigación del Software Testing Institute muestra que la selección sistemática de técnicas (el núcleo de TDS) aumenta las tasas de detección de defectos en un 28-45% para la lógica de negocio con condiciones límite.

TL;DR: Una Test Design Specification cierra la brecha entre la estrategia (Test Plan) y la ejecución (casos de prueba) especificando CÓMO se probará una característica: qué técnicas (partición de equivalencia, BVA, tablas de decisión), criterios de cobertura, requisitos de datos y umbrales de pase/fallo. Escribe TDS para características complejas, de alto riesgo o de cumplimiento crítico. El estándar IEEE 829 define el formato.

Una Test Design Specification (TDS) define cómo se realizarán las pruebas para características específicas. Mientras un Test Plan 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 de casos de prueba y ejecución.

El TDS conecta múltiples artefactos de documentación: referencia trazabilidad de requisitos (ver Test Coverage Reports), especifica necesidades de datos de prueba, y define criterios que alimentan los Test Summary Reports.

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 ✅

“La TDS es el documento que separa el testing estratégico del testing aleatorio. Sin ella, la creación de casos de prueba es básicamente adivinar — obtienes los escenarios en los que el tester pensó ese día. Con una TDS, los casos de prueba se derivan sistemáticamente de técnicas y criterios de cobertura. Puedes medir la completitud, defender las decisiones de cobertura y asegurarte de que el próximo ingeniero continúe exactamente donde lo dejaste.” — Yuri Kan, Senior QA Lead

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.

FAQ

¿Qué es una Test Design Specification?

Una TDS define CÓMO se realizarán las pruebas para características específicas — cerrando la brecha entre plan (estrategia) y casos de prueba (ejecución). Según ISTQB Advanced Level 2024, equipos con TDS encuentran un 34% más de defectos en características complejas. IEEE 829 la define como entregable requerido.

¿En qué se diferencia la TDS del Test Plan?

Test Plan: QUÉ probar y POR QUÉ (alcance, objetivos, recursos). TDS: CÓMO probar características específicas (técnicas, criterios, datos). Un proyecto tiene un Test Plan; puede tener múltiples TDS — una por característica importante.

¿Qué debe incluir una TDS?

Característica bajo prueba, objetivos, técnicas aplicables (con justificación), criterios y mediciones de cobertura, especificaciones de datos (con casos límite), criterios de entrada/salida, criterios de pase/fallo y evaluación de riesgos. Los criterios de cobertura son más críticos — definen cuándo el testing está ‘completo’.

¿Cuándo escribir una TDS?

Para: características complejas con múltiples rutas, requisitos de cumplimiento (FDA, SOX, ISO 26262) y áreas de alto riesgo. Omítela para: características CRUD simples y features experimentales. El esfuerzo debe ser proporcional al riesgo y complejidad.

Ver También

Recursos Oficiales