¿Qué Es el Testing Exploratorio?
El testing exploratorio es un enfoque donde el tester simultáneamente aprende sobre el sistema, diseña pruebas y las ejecuta — todo en un proceso cognitivo continuo. Fue formalizado por James Bach y Cem Kaner, quienes lo definieron como:
“Aprendizaje, diseño de pruebas y ejecución simultáneos.”
A diferencia del testing con scripts donde escribes todos los casos de prueba primero y luego los ejecutas paso a paso, el testing exploratorio se adapta en tiempo real. Lo que descubres en una prueba influye en lo que pruebas después.
La Mentalidad
Un tester exploratorio es como un detective investigando un caso. Empiezas con una hipótesis (“este formulario de login podría ser vulnerable a inyección”), la investigas, descubres nuevas pistas (“el mensaje de error revela el tipo de base de datos”) y las sigues. Cada hallazgo determina tu siguiente movimiento.
Esto requiere:
- Curiosidad — Constantemente preguntar “¿qué pasa si…?”
- Pensamiento crítico — Cuestionar suposiciones y comportamiento esperado
- Conocimiento del dominio — Entender qué debería hacer el software
- Conciencia técnica — Conocer patrones comunes de fallas y áreas de riesgo
Proceso del Testing Exploratorio
Test Charters
Un test charter es una breve declaración de misión que guía una sesión exploratoria.
Formato:
Explorar [objetivo] con [recursos/técnicas] para descubrir [información/riesgos]
Ejemplos:
Explorar el flujo de checkout con valores límite y tarjetas inválidas para descubrir fallas de procesamiento de pagos y gaps en manejo de errores.
Explorar la funcionalidad de búsqueda con caracteres especiales, strings largos y consultas vacías para descubrir problemas de validación de entrada y crashes.
Criterios de Calidad del Charter
Un buen charter es:
- Enfocado — Suficientemente acotado para completar en 60-90 minutos
- Testeable — Define qué estás buscando
- Basado en riesgo — Apunta a áreas donde los bugs son más probables
- Flexible — Deja espacio para descubrimiento y desviación
Touring Heuristics
Los touring heuristics, desarrollados por James Whittaker, proporcionan enfoques estructurados para explorar software:
Tour del Manual. Sigue la documentación paso a paso. ¿Las features documentadas funcionan como se describe?
Tour del Dinero. Prueba las features por las que los clientes pagan — la propuesta de valor principal. Para e-commerce: navegar, buscar, agregar al carrito, checkout.
Tour de Puntos de Referencia. Identifica los landmarks principales (pantallas clave, features importantes) y navega entre ellos en varios órdenes.
Tour Antisocial. Haz todo lo que la aplicación no quiere que hagas. Datos inválidos, saltar pasos requeridos, botón atrás en momentos críticos.
Tour del Día Lluvioso. Inicia operaciones y cancélalas. ¿Qué pasa al cancelar una subida al 50%? ¿Cerrar el navegador durante el checkout?
Tour Obsesivo-Compulsivo. Repite la misma acción muchas veces. Envía el mismo formulario 100 veces. Haz clic rápido en guardar. Esto descubre race conditions y fugas de recursos.
Cuándo Usar Testing Exploratorio
El testing exploratorio es más valioso cuando:
- Llega una nueva feature con mínimas especificaciones
- El tiempo es limitado y necesitas máxima cobertura rápido
- Quieres encontrar bugs que los scripts no detectan — especialmente UX y edge cases
- El sistema es complejo y no puedes predecir todos los escenarios
- Después de la automatización — la exploración encuentra lo inesperado
- Áreas de riesgo necesitan investigación enfocada
Exploratorio vs. Ad Hoc
| Aspecto | Testing Exploratorio | Testing Ad Hoc |
|---|---|---|
| Estructura | Charters, time-boxes, notas | Sin estructura |
| Planificación | Sesión planificada con charter | No planificado |
| Documentación | Notas de sesión, reportes de bugs | Usualmente ninguna |
| Trazabilidad | Rastreable via hojas de sesión | No rastreable |
| Habilidad requerida | Alta (enfoque estructurado) | Cualquier nivel |
| Repetibilidad | Parcial (via notas y charters) | No repetible |
Ejercicio: Escribe Test Charters y Conduce una Exploración
Parte 1: Estás probando una app móvil de delivery de comida. Escribe 3 test charters:
- Para el flujo de colocación de pedidos
- Para el comportamiento bajo malas condiciones de red
- Para la búsqueda y filtrado de restaurantes
Parte 2: Elige un charter y conduce una sesión de 30 minutos. Documenta usando la plantilla de sesión (charter, duración, áreas exploradas, bugs encontrados, riesgos no cubiertos, % en charter).
Parte 3: Después de la sesión, responde: ¿Qué descubriste que no habrías encontrado con scripts? ¿Cómo cambió tu ruta de exploración? ¿Qué explorarías en la próxima sesión?
Pista
Para los charters, sé específico sobre las técnicas (valores límite, interrupciones, acciones rápidas) y los riesgos (pérdida de datos, crashes, cálculos incorrectos). Para la sesión, sigue tu curiosidad.Solución
Parte 1: Charters de Ejemplo
Charter 1 — Pedidos:
Explorar el flujo de pedidos con valores límite (pedido mínimo, máximo de items), adiciones/remociones rápidas y modificaciones simultáneas del carrito para descubrir errores de cálculo, race conditions y problemas de integridad de datos.
Charter 2 — Red degradada:
Explorar el comportamiento bajo red degradada con modo avión, simulación 2G y cortes de red durante pedido y pago para descubrir pérdida de datos, transacciones incompletas, mensajes de error confusos y gaps de recuperación.
Charter 3 — Búsqueda:
Explorar la búsqueda y filtrado con caracteres especiales, emoji, queries extremadamente largos, cambio rápido de filtros para descubrir fallas de búsqueda, resultados incorrectos, degradación de rendimiento y bugs de estado de filtros.
Parte 2: Notas de Sesión de Ejemplo
CHARTER: Explorar el flujo de pedidos con valores límite
DURACIÓN: 30 minutos
ÁREAS EXPLORADAS:
- Agregar item con monto mínimo
- Agregar 99 del mismo item
- Adición/remoción rápida de items
- Aplicar y remover códigos promo durante cambios
BUGS ENCONTRADOS:
- BUG-1 (Medio): Badge del carrito muestra número negativo
momentáneamente al agregar/remover rápidamente.
- BUG-2 (Alto): Aplicar código promo, luego remover el item
al que aplica, sigue mostrando el descuento en el total.
- BUG-3 (Bajo): Cambiar de delivery a pickup no remueve el
cargo de envío hasta refrescar la página.
RIESGOS NO CUBIERTOS:
- Pedidos multi-restaurante
- Pedido con método de pago expirado
% EN CHARTER: 70% en charter, 30% siguiendo el trail del bug de promo
Parte 3: El bug del código promo probablemente no aparecería en scripts porque requiere una secuencia específica de acciones difícil de predecir. Después de encontrar BUG-2, cambié de probar cantidades a probar interacciones de códigos promo — esta adaptación es la fortaleza del testing exploratorio.
Puntos Clave
- El testing exploratorio combina aprendizaje, diseño y ejecución en un proceso cognitivo continuo
- Los test charters proporcionan foco sin restringir el descubrimiento
- Los touring heuristics ofrecen enfoques estructurados para exploración sistemática
- Es una disciplina profesional — no aleatorio ni ad hoc
- Es más valioso para nuevas features, áreas de riesgo, tiempo limitado y encontrar bugs que los scripts no detectan
- Las mejores estrategias combinan testing con scripts para escenarios conocidos con exploración para lo desconocido