Las pruebas exploratorias prosperan en la libertad estructurada: equilibrando investigación guiada con resolución creativa de problemas. Los test charters proporcionan esta estructura, definiendo el alcance, misión y áreas de enfoque para sesiones exploratorias mientras dejan espacio para el juicio del tester y descubrimientos fortuitos. Los charters bien escritos transforman las pruebas ad-hoc en una práctica disciplinada y repetible que genera insights valiosos y documentación exhaustiva de sesiones.
¿Qué es un Test Charter?
Un test charter es un documento conciso (típicamente 1-2 párrafos) que describe:
- Misión: Qué estás tratando de aprender o lograr
- Alcance: Qué partes del sistema explorar
- Recursos: Herramientas, datos, documentación necesaria
- Tiempo: Duración sugerida (usualmente 60-90 minutos)
A diferencia de casos de prueba con pasos predefinidos, los charters proporcionan dirección sin restringir la exploración.
Anatomía de un Test Charter Efectivo
Plantilla Básica
Explorar: [ÁREA/CARACTERÍSTICA]
Con: [RECURSOS/HERRAMIENTAS/DATOS]
Para descubrir: [RIESGOS/INFORMACIÓN/BUGS]
Ejemplo 1: Checkout E-commerce
Explorar: Flujo de procesamiento de pagos
Con: Múltiples métodos de pago (tarjeta de crédito, PayPal, Apple Pay), varios tipos de tarjetas (Visa, MasterCard, Amex), montos extremos ($0.01, $999,999.99), tarjetas vencidas
Para descubrir: Fallos de validación, problemas de manejo de errores, condiciones de carrera en confirmación de pago, vulnerabilidades de seguridad en transmisión de datos de tarjeta
Ejemplo 2: Rendimiento de App Móvil
Explorar: Comportamiento de app bajo inestabilidad de red
Con: Network Link Conditioner (simular 3G, Edge, 100% pérdida de paquetes), Charles Proxy para inspección de tráfico, batería del dispositivo <20%
Para descubrir: Manejo de timeouts, funcionalidad de modo offline, problemas de sincronización de datos, drenaje excesivo de batería, escenarios de crash
Formato de Charter Extendido
## Charter: Pruebas de Estrés de Funcionalidad de Búsqueda
**Misión**: Evaluar rendimiento y resiliencia del motor de búsqueda bajo alta carga y casos extremos
**Alcance**:
- Búsqueda de productos (catálogo de 50,000+ artículos)
- Filtros avanzados (rango de precio, categoría, marca, calificaciones)
- Sugerencias de búsqueda y autocompletado
- Historial de búsqueda y búsquedas guardadas
**Ideas de Prueba**:
- Consultas de búsqueda extremadamente largas (>500 caracteres)
- Caracteres especiales e intentos de inyección SQL
- Unicode y emoji en términos de búsqueda
- Búsquedas concurrentes desde la misma sesión de usuario
- Escritura rápida en autocompletado
- Filtros aplicados en varias combinaciones
**Recursos**:
- Script JMeter para generación de carga
- Dataset de prueba con nombres de productos diversos
- OWASP ZAP para pruebas de seguridad
- DevTools del navegador para perfilado de rendimiento
**Duración**: 90 minutos
**Riesgos a Investigar**:
- Vulnerabilidades de inyección SQL o XSS
- Rendimiento pobre con consultas complejas
- Condiciones de carrera en autocompletado
- Fugas de memoria con búsquedas repetidas
- Resultados inconsistentes con la misma consulta
Heurísticas y Disparadores de Prueba
Los charters efectivos incorporan heurísticas de prueba: principios generales que guían la investigación.
Heurística SFDPOT (James Bach)
Structure (Estructura): Probar la arquitectura y relaciones
- Endpoints API y sus integraciones
- Esquema de base de datos y restricciones de clave foránea
Function (Función): Probar lo que hace el sistema
- Funcionalidad de características según requisitos
- Lógica de negocio y cálculos
Data (Datos): Probar con varias entradas de datos
- Valores límite (mín, máx, justo dentro/fuera de límites)
- Datos inválidos/mal formados
Platform (Plataforma): Probar en diferentes entornos
- Sistemas operativos (Windows, macOS, Linux)
- Navegadores (Chrome, Firefox, Safari, Edge)
Operations (Operaciones): Probar flujos de trabajo de usuario
- Recorridos comunes de usuario
- Procesos de múltiples pasos
Time (Tiempo): Probar comportamiento relacionado con tiempo
- Timeouts y retrasos
- Trabajos programados y tareas cron
Heurística CAN I USE THIS?
- Capability (Capacidad): ¿Hace lo que dice?
- Availability (Disponibilidad): ¿Es accesible cuando se necesita?
- Reliability (Confiabilidad): ¿Funciona consistentemente?
- Compatibility (Compatibilidad): ¿Funciona con otros sistemas?
- Usability (Usabilidad): ¿Los usuarios pueden completar tareas fácilmente?
- Performance (Rendimiento): ¿Es suficientemente rápido?
- Security (Seguridad): ¿Los datos están protegidos?
Toma de Notas Durante Sesiones
# Registro de Sesión Exploratoria
**Charter**: Flujo de procesamiento de pagos
**Tester**: John Doe
**Fecha**: 2024-10-06
**Hora de Inicio**: 10:00 AM
**Duración**: 90 minutos
## Configuración
- Entorno: Staging (v2.3.5)
- Datos de prueba: 10 tarjetas de crédito de prueba, 5 cuentas sandbox PayPal
- Herramientas: Charles Proxy, Browser DevTools
## Línea de Tiempo
### 10:05 - Validación de Tarjeta de Crédito
- Probado Visa, MasterCard, Amex con números válidos
- ✅ Todas aceptadas correctamente
- ❌ BUG-1234: Validación CVV de Amex acepta 3 dígitos (debería requerir 4)
### 10:20 - Manejo de Tarjeta Vencida
- Probado tarjetas vencidas hace 1 mes, 1 año, mes actual exacto
- ✅ Mensaje de error claro mostrado
- ⚠️ PREGUNTA: ¿Deberían aceptarse tarjetas que vencen el mes actual?
### 10:35 - Montos de Caso Extremo
- $0.01: ✅ Procesado exitosamente
- $999,999.99: ❌ BUG-1235: Timeout del servidor después de 30 segundos
- $0.00: ✅ Correctamente rechazado con error "Monto inválido"
## Bugs Encontrados
1. **BUG-1234**: Validación CVV de Amex incorrecta (Prioridad alta)
2. **BUG-1235**: Timeout en montos muy grandes (Media)
3. **BUG-1236**: Sin timeout en fallo de red (Alta)
4. **BUG-1237**: Posibles cargos duplicados (Crítica)
## Cobertura de Pruebas
- ✅ Reglas de validación de tarjeta
- ✅ Manejo de tarjeta vencida
- ✅ Montos de caso extremo
- ✅ Escenarios de fallo de red
- ❌ Procesamiento de reembolsos (fuera de alcance)
Reporte de Debriefing de Sesión
# Reporte de Debriefing de Pruebas Exploratorias
**Charter**: Pruebas de estrés de funcionalidad de búsqueda
**ID de Sesión**: ET-2024-106-01
**Tester**: Jane Smith
**Fecha**: 2024-10-06
**Duración**: 90 minutos
---
## Resumen Ejecutivo
Realizado pruebas exploratorias de funcionalidad de búsqueda enfocándose en rendimiento y seguridad bajo condiciones de estrés. **Encontrados 3 bugs de severidad alta** relacionados con vulnerabilidad de inyección SQL, condiciones de carrera en autocompletado y fugas de memoria.
**Evaluación General de Riesgo**: 🔴 **ALTA** - Vulnerabilidad de inyección SQL bloquea lanzamiento
---
## Hallazgos
### 🔴 Problemas Críticos
**BUG-2301: Vulnerabilidad de Inyección SQL en Búsqueda**
- **Severidad**: Crítica
- **Descripción**: Parámetro de consulta no sanitizado. Input `' OR '1'='1` devuelve catálogo completo
- **Impacto**: Exposición completa de base de datos, potencial brecha de datos
- **Recomendación**: **BLOQUEAR LANZAMIENTO** hasta corrección
### 🟠 Problemas de Alta Prioridad
**BUG-2302: Condición de Carrera en Autocompletado**
- **Severidad**: Alta
- **Descripción**: Escritura rápida causa que solicitudes de autocompletado retornen fuera de orden
- **Impacto**: Experiencia de usuario confusa
**BUG-2303: Fuga de Memoria en Resultados de Búsqueda**
- **Severidad**: Alta
- **Descripción**: Búsquedas repetidas causan crecimiento indefinido de memoria del navegador
- **Impacto**: Desaceleración del navegador, eventual crash en dispositivos móviles
---
## Observaciones Positivas
✅ La búsqueda manejó Unicode y emoji correctamente
✅ Mensajes de error claros y útiles
✅ Degradación elegante cuando backend es lento
---
## Recomendaciones
1. **Inmediato**: Corregir inyección SQL (BUG-2301) antes de cualquier lanzamiento
2. **Alta Prioridad**: Abordar condición de carrera y fuga de memoria
3. **Mejora Futura**: Implementar caché de resultados de consulta
---
**Aprobación**: Revisión de Gerente QA Requerida
**Distribución**: Equipo de Ingeniería, Product Owner, Release Manager
Mejores Prácticas
1. Ser Específico pero Flexible
Charter Pobre:
Explorar: La aplicación
Para descubrir: Bugs
Buen Charter:
Explorar: Lógica de cálculo de carrito de compras con códigos promocionales, descuentos por cantidad y reglas fiscales
Con: Combinaciones de casos extremos (múltiples códigos promo, códigos vencidos, reglas fiscales internacionales)
Para descubrir: Errores de cálculo, problemas de redondeo, vulnerabilidades de apilamiento de cupones
2. Delimitar Sesiones por Tiempo
Limitar sesiones a 60-120 minutos. Sesiones más largas pierden enfoque.
3. Usar Personas y Escenarios
Charter: Usabilidad de app móvil para usuarios mayores
Persona: Margaret, 68, experiencia tecnológica limitada, usa lentes de lectura
Escenarios:
- Configuración inicial de app y registro por primera vez
- Encontrar y comprar un producto
4. Documentar Lo Que No Probaste
Notar explícitamente áreas fuera de alcance. Esto previene suposiciones sobre cobertura.
Conclusión
Los test charters bien elaborados transforman las pruebas exploratorias de investigación no estructurada en una práctica disciplinada y documentable. Al proporcionar misiones claras, aprovechar heurísticas de prueba, mantener registros detallados de sesiones y producir reportes exhaustivos de debriefing, los equipos obtienen los beneficios tanto de la libertad exploratoria como de la gestión estructurada de pruebas.
La clave es el equilibrio: los charters deben guiar sin restringir, documentar sin burocracia y permitir exploración creativa mientras aseguran responsabilidad y transferencia de conocimiento.