¿Qué es el Exploratory Testing?
El Exploratory Testing es un enfoque simultáneo de aprendizaje, diseño de pruebas y ejecución donde los testers investigan activamente el software para entender su comportamiento y descubrir defectos. A diferencia del testing con scripts donde los casos de prueba están predefinidos, el exploratory testing se basa en la creatividad, intuición y conocimiento del dominio del tester para guiar las actividades de testing en tiempo real.
Características Clave:
- Actividades simultáneas: Aprendizaje, diseño y ejecución de tests ocurren concurrentemente
- Exploración sin scripts: Sin casos de prueba paso a paso predefinidos
- Dirigido por el tester: Aprovecha habilidades, experiencia y creatividad del tester
- Adaptativo: El testing se adapta basándose en descubrimientos e insights
- Dependiente del contexto: Se enfoca en áreas de mayor valor o riesgo
El exploratory testing no es caos aleatorio o no estructurado—es un enfoque disciplinado guiado por objetivos de testing, restricciones y heurísticas.
Exploratory vs Scripted Testing
| Aspecto | Exploratory Testing | Scripted Testing |
|---|---|---|
| Diseño de Tests | Durante la ejecución | Antes de la ejecución |
| Documentación | Notas ligeras, reportes de sesión | Casos de prueba detallados anticipadamente |
| Flexibilidad | Alta - se adapta a descubrimientos | Baja - sigue pasos predefinidos |
| Aprendizaje | Continuo durante testing | Principalmente durante fase de diseño |
| Mejor Para | Encontrar issues inesperados, casos edge | Regresión, compliance, repetibilidad |
| Cobertura | Guiada por riesgo e intuición | Sistemática y medible |
| Tiempo para Comenzar | Inmediato | Requiere tiempo de preparación |
Importante: El exploratory y scripted testing son enfoques complementarios, no competidores. Las estrategias de testing maduras usan ambos.
Por Qué Importa el Exploratory Testing
Ventajas
- Descubre defectos inesperados: Encuentra issues que los tests con scripts pierden
- Feedback rápido: Puede comenzar inmediatamente sin preparación extensiva
- Se adapta al cambio: Enfoque flexible ideal para entornos ágiles
- Aprovecha expertise: Aprovecha conocimiento e intuición del tester
- Testea perspectiva del usuario: Imita exploración de usuario real
- Investiga escenarios complejos: Explora interacciones y workflows
- Costo-efectivo: Sin overhead de escribir casos de prueba detallados para testing único
Limitaciones
- Menos repetible: El mismo test puede no ejecutarse idénticamente
- Depende de habilidad del tester: La calidad varía según capacidad del tester
- Más difícil medir cobertura: Sin cuenta predefinida de casos de prueba
- Desafíos de documentación: Requiere disciplina para documentar hallazgos
- Difícil de delegar: No se puede entregar fácilmente a otros
Cuándo Usar Exploratory Testing
Escenarios ideales:
- Nuevas features: Entender y testear funcionalidad no familiar
- Bugs críticos: Investigación profunda de issues de producción
- Restricciones de tiempo: Necesita feedback rápido sin preparación de casos de prueba
- Evaluación de usabilidad: Evaluar experiencia de usuario y workflows
- Integraciones complejas: Testear interacciones entre componentes
- Suplementos de regresión: Complementar regresión automatizada con insight humano
- Enfoque basado en riesgo: Investigar áreas de alto riesgo identificadas en análisis de riesgo
Técnicas y Enfoques Centrales
1. Session-Based Test Management (SBTM)
SBTM proporciona estructura al exploratory testing mediante sesiones con time-box y charter.
Componentes:
Test Charter: Una declaración de misión para la sesión de testing
Template de Charter:
EXPLORAR: [área objetivo]
CON: [recursos, herramientas]
PARA DESCUBRIR: [información, riesgos, defectos]
Ejemplo de Charter:
EXPLORAR: Workflow de procesamiento de pagos
CON: Cuentas de tarjetas de crédito de prueba, herramienta de throttling de red
PARA DESCUBRIR: Casos edge en fallos de pago, manejo de timeouts, mensajes de error
Time-box: Duración fija (típicamente 60-90 minutos) para testing enfocado
Debriefing: Documentación post-sesión de hallazgos, preguntas, issues
Ejemplo de Reporte de Sesión:
## Reporte de Sesión de Exploratory Testing
**Charter**: Explorar funcionalidad de login con varias combinaciones de credenciales para descubrir casos edge de autenticación
**Tester**: Sarah Martínez
**Fecha**: 2025-10-02
**Duración**: 90 minutos
### Áreas Cubiertas:
- Combinaciones válidas/inválidas de username y password
- Sensibilidad a mayúsculas en password
- Caracteres especiales en credenciales
- Bloqueo de cuenta después de intentos fallidos
- Comportamiento de timeout de sesión
- Funcionalidad "Remember Me"
### Bugs Encontrados:
1. **[P2]** Bloqueo de cuenta persiste incluso después de reset exitoso de password
2. **[P3]** Mensaje de error revela si username existe (issue de seguridad)
3. **[P4]** "Remember Me" no persiste a través de reinicio de navegador
### Preguntas Levantadas:
- ¿Cuál es la duración prevista del bloqueo de cuenta? (spec poco clara)
- ¿Debería CAPTCHA activarse después de N intentos fallidos?
### Cobertura de Testing: 85% de objetivos de charter
### Nuevas Ideas de Testing Generadas:
- Testear intentos de login concurrentes desde múltiples dispositivos
- Explorar reset de password con tokens expirados
2. Testing Basado en Heurísticas
Las heurísticas son reglas prácticas que guían la exploración. Heurísticas comunes de testing incluyen:
Heurística CRUD
Testear operaciones de Crear, Leer (Read), Actualizar (Update), Eliminar (Delete) para entidades de datos.
Ejemplo: Testing de sistema de gestión de posts de blog
Crear:
- Crear post con campos mínimos
- Crear con todos los campos poblados
- Crear con caracteres especiales en título
- Crear con contenido muy largo
Leer:
- Ver posts propios vs posts de otros
- Filtrar/buscar posts
- Paginación con tamaños de página variados
Actualizar:
- Actualizar solo título, solo contenido, ambos
- Actualizar posts publicados vs borradores
- Actualizaciones concurrentes desde múltiples usuarios
Eliminar:
- Eliminar borradores vs posts publicados
- Eliminar con comentarios adjuntos
- Recuperar posts eliminados (si está soportado)
Testing de Límites
Explorar límites y boundaries:
- Valores mínimo/máximo
- Inputs vacíos/null
- Inputs muy grandes (overflow)
- Números negativos donde se esperan positivos
Principio Goldilocks
Testear con inputs que son “muy pequeños,” “muy grandes,” y “justos”
Heurística de Consistencia
Buscar inconsistencias:
- Comportamiento de elementos UI en diferentes pantallas
- Reglas de validación de campos en formularios similares
- Terminología usada en diferentes partes de la aplicación
SFDIPOT (San Francisco Depot)
Triggers de exploración:
- Structure (Estructura): Arquitectura, componentes, integraciones
- Function (Función): Features y capacidades
- Data (Datos): Input/output, formatos, validación
- Interfaces: APIs, UI, puntos de integración
- Platform (Plataforma): Variaciones de OS, navegador, dispositivo
- Operations (Operaciones): Workflows, user journeys
- Time (Tiempo): Timeouts, scheduling, time zones
3. Tours de la Aplicación
Los “Testing Tours” de James Whittaker proporcionan frameworks de exploración:
The Guidebook Tour
Seguir documentación de usuario/guías de ayuda y verificar precisión.
The Money Tour
Testear features que generan revenue o tienen alto valor de negocio.
The Landmark Tour
Visitar features clave con las que los usuarios interactúan más frecuentemente.
The Intellectual Tour
Testear las features más complejas, técnicamente desafiantes.
The FedEx Tour
Seguir datos a través del sistema completo de extremo a extremo.
The Bad Neighborhood Tour
Explorar áreas con issues conocidos o alta densidad de defectos.
The Saboteur Tour
Intentar intencionalmente romper la aplicación con inputs inválidos.
Ejemplo: Money Tour para E-commerce
1. Navegar productos → Ver detalle de producto
2. Agregar al carrito → Modificar cantidad
3. Proceder al checkout → Ingresar info de envío
4. Ingresar detalles de pago → Completar compra
5. Recibir confirmación → Verificar estado de orden
En cada paso, explorar variaciones:
- Diferentes tipos de productos
- Múltiples items en carrito
- Varios métodos de pago
- Códigos de descuento
- Usuario guest vs registrado
4. Attack-Based Testing
Estresar deliberadamente el sistema para exponer debilidades:
Confundir la Aplicación
- Ingresar tipos de datos inesperados
- Mezclar mayúsculas/minúsculas inconsistentemente
- Usar caracteres especiales en todas partes
Abrumar la Aplicación
- Subir archivos de tamaño máximo
- Enviar formularios rápidamente
- Crear miles de registros
Interrumpir Workflows
- Saltar pasos en procesos multi-paso
- Usar botón back del navegador en momentos inesperados
- Refrescar páginas durante procesamiento
Violar Restricciones
- Manipular URLs/parámetros directamente
- Modificar campos de formulario ocultos
- Enviar requests fuera de secuencia
5. Pair Testing
Dos testers (o tester + desarrollador) exploran juntos:
- Uno conduce (opera la aplicación)
- Uno observa (toma notas, sugiere ideas)
- Combinan diferentes perspectivas y expertise
Beneficios:
- Compartir conocimiento en tiempo real
- Cobertura más amplia (dos pares de ojos)
- Discusión inmediata de hallazgos
- Oportunidades de mentoring
Conclusión
El exploratory testing es un complemento poderoso al scripted testing, aprovechando la creatividad e intuición humana para descubrir defectos que los casos de prueba predefinidos pierden. Al proporcionar estructura mediante session-based management, charters y heurísticas, el exploratory testing se convierte en una práctica disciplinada y medible que entrega valor significativo.
Puntos Clave:
- El exploratory testing es investigación estructurada, no clic aleatorio
- Usa charters y time-boxes para proporcionar enfoque y límites
- Aplica heurísticas y tours para guiar la exploración sistemáticamente
- Combina con automatización para cobertura comprehensiva
- Documenta continuamente para capturar insights valiosos
- Mide y mejora usando reportes de sesión y métricas
En el desarrollo de software moderno, donde los requisitos evolucionan rápidamente y las expectativas de los usuarios son altas, el exploratory testing proporciona la flexibilidad y el insight necesarios para entregar aplicaciones verdaderamente robustas y user-friendly. Hazlo una parte central de tu estrategia de testing.