Introducción al Exploratory Testing
El exploratory testing es aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas. A diferencia del testing con script donde ejecutas casos de prueba predefinidos, el exploratory testing es un enfoque investigativo donde el tester controla activamente el diseño de las pruebas mientras se realizan, usando información obtenida durante el testing para diseñar pruebas nuevas y mejores.
Piensa en el exploratory testing (como se discute en From Manual to Automation: Complete Transition Guide for QA Engineers) (como se discute en Will AI Replace QA Engineers by 2030? The Future of Testing Profession) como la diferencia entre seguir una ruta GPS y explorar una nueva ciudad a pie. El GPS te lleva a tu destino eficientemente, pero caminar por ahí te permite descubrir joyas ocultas, entender el carácter del vecindario y encontrar problemas que el GPS nunca mencionó.
En esta guía completa, exploraremos el arte y la ciencia del exploratory testing—desde enfoques estructurados como session-based testing hasta técnicas creativas como tours, desde estrategias de documentación hasta heurísticas poderosas que guían tu investigación.
¿Qué es el Exploratory Testing?
Definición
Exploratory testing es un enfoque de testing de software que enfatiza la libertad y responsabilidad del tester para optimizar continuamente el valor de su trabajo tratando el aprendizaje relacionado con testing, diseño de pruebas, ejecución de pruebas e interpretación de resultados como actividades mutuamente de soporte que corren en paralelo a lo largo del proyecto.
Características clave:
- Impulsado por aprendizaje: Entender el sistema mientras se prueba
- Dependiente del contexto: Se adapta a lo que encuentras
- Intensivo en habilidades: Depende de la experiencia del tester y pensamiento crítico
- Simultáneo: Diseño y ejecución suceden juntos
- Time-boxed: A menudo estructurado en sesiones enfocadas
Exploratory vs Scripted Testing
Scripted testing:
1. Escribir casos de prueba
2. Revisar casos de prueba
3. Ejecutar casos de prueba
4. Reportar resultados
Ventajas:
- Repetible
- Cobertura medible
- Bueno para regresión
- Testers junior pueden ejecutar
Desventajas:
- Lento para adaptar
- Pierde escenarios inesperados
- Puede ser ejecución sin pensar
Exploratory testing:
1. Charter/Misión → Test → Aprender → Adaptar → Test → Aprender...
Ventajas:
- Encuentra bugs sorprendentes
- Se adapta en tiempo real
- Involucra creatividad del tester
- Feedback rápido
Desventajas:
- Más difícil de medir
- Requiere testers habilidosos
- Menos repetible
- Puede parecer no estructurado
Realidad: Estos no son enfoques opuestos—son complementarios. Las mejores estrategias de testing usan ambos.
Cuándo Usar Exploratory Testing
Escenarios ideales:
- Nuevas características: Entender funcionalidad desconocida
- Líneas de tiempo cortas: Necesidad de encontrar bugs rápidamente
- Requisitos vagos: Cuando especificaciones están incompletas
- Después de automatización: Encontrar lo que los scripts pierden
- Rutas críticas de usuario: Asegurar usabilidad del mundo real
- Investigación de regresión: Entender por qué fallan tests automatizados
- Security testing: Buscar vulnerabilidades creativamente
- Evaluación de usabilidad: Experimentar el journey del usuario
No ideal para:
- Testing de cumplimiento requiriendo audit trails
- Requisitos de repetibilidad exacta
- Escenarios que automatización maneja bien
- Cuando testers carecen de conocimiento del producto
Session-Based Test Management (SBTM)
¿Qué es SBTM?
Session-Based Test Management es un enfoque estructurado de exploratory testing que proporciona medibilidad y responsabilidad mientras preserva la libertad del tester para explorar.
Conceptos core:
- Charter: La misión u objetivo para la sesión
- Session: Un período time-boxed de testing ininterrumpido (usualmente 45-120 minutos)
- Debriefing: Revisión de lo que sucedió durante la sesión
- Métricas: Rastrear tiempo y cobertura
El Charter de Sesión
Un charter define qué estás probando, por qué y cómo.
Formato de charter:
Explorar [área]
Con [recursos]
Para descubrir [información]
Ejemplos:
Charter 1:
Explorar: Flujo de procesamiento de pago
Con: Varios tipos de tarjetas de crédito y montos
Para descubrir: Validación, manejo de errores y casos edge
Charter 2:
Explorar: Configuraciones de perfil de usuario
Con: Diferentes roles y permisos de usuario
Para descubrir: Problemas de control de acceso e integridad de datos
Charter 3:
Explorar: Funcionalidad de subida de archivos
Con: Varios tipos de archivos, tamaños y casos edge
Para descubrir: Vulnerabilidades de seguridad y manejo de archivos malformados
Charter 4:
Explorar: Funcionalidad de búsqueda
Con: Diferentes tipos de consulta (parcial, exacta, caracteres especiales)
Para descubrir: Problemas de rendimiento y relevancia
Características de buen charter:
- Específico suficiente para enfocar testing
- Amplio suficiente para permitir exploración
- Apropiado en tiempo para longitud de sesión
- Misión clara que guía pero no restringe
Anti-patrones de charter:
- ❌ Demasiado vago: "Probar la aplicación"
- ❌ Demasiado específico: "Verificar que botón de login es azul"
- ❌ Demasiado amplio: "Encontrar todos los bugs en el sistema"
- ❌ Sin foco: "Hacer clic por ahí y ver qué pasa"
✓ Justo: "Explorar autenticación con varias combinaciones de credenciales para descubrir vulnerabilidades de seguridad"
Planificando una Sesión
Antes de la sesión:
1. Definir charter
- ¿Qué estás probando?
- ¿Qué preguntas quieres responder?
- ¿Qué riesgos te preocupan?
2. Reunir recursos
- Datos de prueba
- Herramientas
- Acceso a entorno
- Documentación
3. Establecer time box
- Usualmente 60-90 minutos
- Suficientemente corto para mantener foco
- Suficientemente largo para entrar en flujo
4. Minimizar interrupciones
- Bloquear calendario
- Silenciar notificaciones
- Establecer expectativa de tiempo de foco
Durante la Sesión
El ciclo de testing:
1. Comenzar con charter
2. Explorar y probar
3. Notar algo interesante
4. Investigar más profundo
5. Encontrar un bug o aprender algo nuevo
6. Documentar brevemente
7. Continuar explorando
8. Seguir nuevos hilos
9. Regresar a charter si te desvías demasiado
10. Notar ideas para futuras sesiones
Asignación de tiempo (sesión típica de 90 minutos):
Setup de sesión: 5 minutos
Testing: 75 minutos
Reporte de bugs: 5 minutos
Toma de notas: 5 minutos (a lo largo)
Toma de notas en tiempo real:
Mantener log de testing:
- Qué estás probando
- Qué observas
- Preguntas que surgen
- Ideas para más testing
- Bugs encontrados
- Tiempo gastado
Ejemplo de log:
10:00 - Sesión iniciada: Charter de procesamiento de pago
10:05 - Probando flujo de tarjeta de crédito válida - funciona como esperado
10:15 - Probando números de tarjeta inválidos - mensajes de error claros
10:20 - Pregunta: ¿Qué pasa con tarjetas expiradas?
10:25 - Bug encontrado: Tarjeta expirada procesada de todos modos! Registrado como BUG-123
10:35 - Probando montos de pago - números negativos...
10:37 - Bug: Monto negativo crea crédito! BUG-124
10:45 - Explorando flujo de reembolso...
Después de la Sesión: Debriefing
Reporte de sesión debe incluir:
Charter: [Qué estabas probando]
Duración: [Tiempo real gastado]
Notas de prueba: [Qué hiciste, qué encontraste]
Bugs encontrados: [Lista con IDs]
Issues: [Blockers o preocupaciones]
Preguntas: [Cosas de las que no estás seguro]
Nuevos charters: [Ideas para futuras sesiones]
Cobertura: [Qué fue probado vs no probado]
Ejemplo de reporte de sesión:
REPORTE DE SESIÓN
Charter: Explorar procesamiento de pago con varios escenarios de tarjeta de crédito
para descubrir problemas de validación y seguridad
Duración: 90 minutos
Áreas Probadas:
- Procesamiento válido de tarjeta de crédito (Visa, MasterCard, Amex)
- Manejo de número de tarjeta inválido
- Manejo de tarjeta expirada
- Diferentes montos de pago (pequeños, grandes, decimales)
- Caracteres especiales en nombre del titular
- Pagos concurrentes
Bugs Encontrados:
- BUG-123: Tarjetas de crédito expiradas son aceptadas y procesadas
- BUG-124: Montos de pago negativos crean créditos
- BUG-125: Vulnerabilidad XSS en campo de nombre del titular
Issues:
- Entorno de prueba fue lento, afectando productividad
- No pude probar tarjetas internacionales (bloqueadas en env de prueba)
Preguntas:
- ¿Cuál es el comportamiento esperado para transacciones de $0.00?
- ¿Deberíamos manejar tarjetas que expiran este mes de manera diferente?
Ideas de Nuevos Charters:
- Explorar procesamiento de pago con tarjetas de crédito internacionales
- Investigar casos edge de flujo de reembolso
- Probar escenarios de pago concurrentes bajo carga
Cobertura:
Probado: Camino feliz básico, casos de error, seguridad básica
No probado: Rendimiento a escala, todos tipos de tarjetas internacionales
Notas:
El foco fue en seguridad y validación. Encontrado issue crítico
con tarjetas expiradas. Recomiendo priorizar corrección de BUG-123.
Métricas SBTM
Rastrear métricas para mostrar valor:
1. Desglose de tiempo de sesión:
Tiempo total de sesión: 90 minutos
- Ejecución de prueba: 70 minutos (78%)
- Investigación de bugs: 10 minutos (11%)
- Setup/admin: 10 minutos (11%)
2. Rastreo de cobertura:
Áreas en charter: 5
Áreas probadas: 4
Áreas no probadas: 1
Cobertura: 80%
3. Métricas de productividad:
Sesiones completadas: 20
Bugs encontrados: 15
Bugs críticos: 3
Tiempo al primer bug: Promedio 15 minutos
4. Indicadores de aprendizaje:
Preguntas levantadas: 45
Charters generados de sesiones: 12
Brechas de documentación identificadas: 8
Tour-Based Testing
¿Qué son los Tours?
Los tours son patrones o temas predefinidos para explorar una aplicación, como un guía turístico mostrándote diferentes aspectos de una ciudad. Cada tour se enfoca en una perspectiva particular o tipo de testing.
La Metáfora del Turista
Imagina que estás visitando una nueva ciudad:
- Tour del Distrito de Negocios: Ver donde sucede el trabajo
- Tour del Distrito de Entretenimiento: Experimentar vida nocturna y diversión
- Tour Histórico: Aprender la historia de la ciudad
- Tour de Callejón Trasero: Encontrar áreas ocultas y menos pulidas
Similarmente, los tours de software exploran diferentes aspectos de una aplicación.
Tipos de Tours
Tours del Distrito de Negocios (Enfocado en Usuario)
1. Tour de Guía
Sigue los caminos "oficiales"—usa la aplicación exactamente como está documentado
en guías de usuario y tutoriales.
Propósito: Verificar precisión de documentación
Preguntas a hacer:
- ¿Los pasos documentados funcionan?
- ¿Las capturas de pantalla están actualizadas?
- ¿Las instrucciones son claras?
- ¿El comportamiento actual coincide con el comportamiento descrito?
Ejemplo: Sitio e-commerce
- Seguir la guía "Cómo hacer tu primera compra"
- Probar el tutorial "Cómo devolver un artículo"
- Ejecutar las instrucciones "Cómo rastrear tu pedido"
2. Tour del Dinero
Sigue los caminos que hacen dinero o entregan valor primario.
Propósito: Probar funcionalidad crítica de negocio
Enfocarse en:
- Características generadoras de ingresos
- Propuestas de valor core
- Características por las que clientes pagan
- Embudos de conversión
Ejemplo: Servicio de suscripción
- Flujo de registro → Pago → Acceso a características premium
- Actualizar a tier superior
- Proceso de renovación
- Programa de referidos
3. Tour de Landmark
Prueba las características más prominentes, visibles o comercializadas.
Propósito: Verificar que características destacadas funcionan
Enfocarse en:
- Características en materiales de marketing
- Elementos en navegación principal
- Capacidades anunciadas
- Escenarios demo
Ejemplo: Herramienta de gestión de proyectos
- Vista de tablero (si es la característica estrella)
- Colaboración en tiempo real
- Sincronización de app móvil
- Integraciones con herramientas populares
4. Tour FedEx
Sigue datos a través del sistema—desde entrada hasta salida, a través de todos
los pasos de procesamiento.
Propósito: Probar flujo e integridad de datos
Rastrear:
- Creación de datos
- Transformación de datos
- Almacenamiento de datos
- Recuperación de datos
- Exportación de datos
Ejemplo: Sistema CRM
- Crear contacto → Asignar a rep de ventas → Agregar a campaña →
Rastrear interacciones → Generar reporte → Exportar datos
Tours del Distrito de Entretenimiento (Experiencia de Usuario)
5. Tour de Supermodelo
Enfocarse en la interfaz de usuario y presentación visual.
Propósito: Evaluar estética y diseño visual
Buscar:
- Consistencia visual
- Alineación y espaciado
- Esquema de color
- Tipografía
- Diseño responsive
- Accesibilidad
Ejemplo:
- Verificar que todos los botones tienen estilo consistente
- Verificar comportamiento responsive en diferentes tamaños de pantalla
- Probar modo oscuro
- Validar contraste de color
- Verificar bugs visuales (texto superpuesto, imágenes cortadas)
6. Tour de Scottish Pub
Probar cada menú, botón y característica que puedas encontrar.
Propósito: Verificar que todos los elementos interactivos funcionan
Probar:
- Cada botón
- Cada enlace
- Cada elemento de menú
- Cada campo de formulario
- Cada atajo de teclado
Ejemplo: Página de configuraciones
- Hacer clic en cada pestaña
- Alternar cada switch
- Guardar cada configuración
- Probar cada opción de dropdown
7. Tour de Couch Potato
Probar con esfuerzo mínimo—comportamiento de usuario perezoso.
Propósito: Ver qué pasa con entrada mínima
Probar:
- Omitir campos opcionales
- Usar defaults en todas partes
- Aceptar todos los defaults
- Tomar el camino de menor resistencia
Ejemplo: Configuración de cuenta
- Omitir foto de perfil
- Usar configuraciones por defecto
- No llenar campos opcionales
- Aceptar opciones recomendadas
Tours del Distrito Histórico (Compatibilidad Retroactiva)
8. Tour de Callejón Trasero
Ir a características menos visibles, antiguas o raramente usadas.
Propósito: Encontrar áreas descuidadas
Enfocarse en:
- Características legacy
- Paneles admin
- Páginas de configuraciones
- Páginas de error
- Documentación de ayuda
- Características deprecadas aún accesibles
Ejemplo:
- Funcionalidad antigua de import/export
- Generadores de reportes legacy
- Modos de compatibilidad
- Herramientas de debugging admin
9. Tour de Museo
Probar con datos antiguos, formatos antiguos, navegadores antiguos, dispositivos antiguos.
Propósito: Verificar compatibilidad retroactiva
Probar con:
- Formatos de archivo antiguos
- Datos de versiones previas
- Navegadores más antiguos
- Dispositivos legacy
- Datos históricos
Ejemplo:
- Importar archivos creados hace años
- Usar IE11 o navegador más antiguo
- Probar en iPhone 6
- Cargar cuenta con historial de 10 años
Tours del Distrito Sórdido (Testing Negativo)
10. Tour de Saboteador
Intentar romper cosas intencionalmente.
Propósito: Encontrar problemas de seguridad y estabilidad
Probar:
- Intentos de inyección SQL
- Intentos XSS
- Buffer overflows
- Entradas inválidas
- Bypasses de autenticación
Ejemplo:
- Ingresar JavaScript en campos de texto
- Usar ' OR '1'='1 en entradas
- Subir ejecutable como imagen
- Manipular URLs
- Alterar cookies
11. Tour Obsesivo-Compulsivo
Repetir la misma acción muchas veces.
Propósito: Encontrar problemas con repetición
Probar:
- Clic rápido
- Múltiples envíos
- Muchos artículos en carrito
- Miles de registros
- Texto muy largo
Ejemplo:
- Hacer clic en botón guardar 100 veces rápidamente
- Agregar 1000 artículos a lista
- Ingresar texto de 10,000 caracteres
- Crear 50 pestañas de navegador
12. Tour de Giro Equivocado
Tomar cada camino equivocado posible.
Propósito: Probar manejo de errores
Probar:
- Credenciales incorrectas
- Entradas inválidas
- Sesiones expiradas
- Parámetros faltantes
- Enlaces rotos
- Páginas 404
Ejemplo:
- Login con contraseña incorrecta
- Enviar formulario con todos datos inválidos
- Navegar a URLs no existentes
- Dejar sesión expirar mid-workflow
- Eliminar parámetros URL requeridos
Tours de Testing Extremo
13. Tour All-Nighter
Ejecutar pruebas de larga duración.
Propósito: Encontrar problemas dependientes del tiempo
Probar:
- Dejar app abierta por horas
- Ejecutar procesos overnight
- Probar exactamente a medianoche
- Cruzar zonas horarias
- Transiciones de horario de verano
Ejemplo:
- Dejar sesión activa por 24 horas
- Programar reportes a medianoche
- Probar cambios de zona horaria
- Ejecutar procesos batch overnight
14. Tour del Recolector de Basura
Llenar el sistema con basura y ver qué se rompe.
Propósito: Probar gestión de recursos
Crear:
- Cuentas dummy
- Datos basura
- Archivos grandes
- Muchos registros
- Almacenamiento completo
Ejemplo:
- Subir tamaño máximo de archivo
- Crear miles de registros de prueba
- Llenar almacenamiento permitido
- Maximizar todos los límites
Usando Tours Efectivamente
Combinando tours:
Sesión 1: Tour del Dinero + Tour FedEx
→ Probar flujo crítico de negocio e integridad de datos
Sesión 2: Tour de Supermodelo + Tour de Museo
→ Probar consistencia UI en navegadores antiguos
Sesión 3: Tour de Saboteador + Tour de Giro Equivocado
→ Deep dive de seguridad y manejo de errores
Adaptación de tours:
Personalizar tours para tu aplicación:
- ¿App móvil? Agregar "Tour de Una Mano" (solo alcance de pulgar)
- ¿API? Agregar "Tour de Contrato" (probar contratos API)
- ¿Dashboard? Agregar "Tour de Data Viz" (probar todos los gráficos)
- ¿Heavy en formularios? Agregar "Tour de Tecla Tab" (navegar solo por teclado)
Heurísticas para Exploratory Testing
¿Qué son las Heurísticas?
Las heurísticas son reglas de dedo, atajos o ayudas de pensamiento que ayudan a testers saber dónde buscar y qué probar. No son garantías—son suposiciones educadas basadas en experiencia.
Heurísticas de Testing
Heurística CRUD
Probar operaciones Create, Read, Update, Delete para todas las entidades.
Para cada objeto de datos, probar:
✓ Crear nuevas instancias
✓ Leer/ver instancias
✓ Actualizar/modificar instancias
✓ Eliminar/remover instancias
También probar:
- Crear sin campos requeridos
- Crear duplicado
- Leer no existente
- Actualizar con datos inválidos
- Actualizar no existente
- Eliminar e intentar acceder
- Eliminar y recrear con mismo ID
Heurística Goldilocks
Probar muy poco, demasiado y justo.
Para cada cantidad o valor:
- Muy pequeño: 0, 1, mínimo
- Muy grande: máximo, máximo+1, infinito
- Justo: valor típico
Ejemplos:
- Subida de archivo: 0 bytes, 1 byte, tamaño máx, máx+1
- Campo de texto: vacío, 1 char, longitud máx, máx+1
- Lista: 0 items, 1 item, muchos items, items máx
- Precio: $0, $0.01, $9999.99, negativo, no numérico
Heurística SFDIPOT
Structure, Function, Data, Interfaces, Platform, Operations, Time
Structure: Arquitectura, organización de código
Function: Qué hacen las características
Data: Flujo de información y almacenamiento
Interfaces: UI, API, integraciones
Platform: OS, navegador, dispositivo
Operations: Instalar, actualizar, configurar
Time: Timing, secuencias, programación
Heurística de Límites
Los errores aman límites—probar en bordes.
Límites comunes:
- Valores min/máx
- Primeros/últimos items
- Inicio/fin de períodos de tiempo
- Vacío/lleno
- Logged in/logged out
- Conectado/desconectado
Ejemplos:
- Primer día del mes/año
- Último registro en base de datos
- Exactamente a medianoche
- Tamaño máximo de archivo
- Carrito vacío vs carrito lleno
Heurística de Consistencia
Cosas que deberían coincidir, deberían coincidir.
Verificar consistencia en:
- Diferentes páginas/pantallas
- Diferentes navegadores/dispositivos
- Diferentes roles de usuario
- Diferentes idiomas
- Diferentes estados
Ejemplos:
- ¿El botón "Submit" siempre es "Submit" o a veces "Send"?
- ¿Todos los campos de fecha usan mismo formato?
- ¿Los mensajes de error son consistentes en estilo?
- ¿La app móvil coincide con web app?
Heurística CRUD + SCAN
Más allá de CRUD básico, también probar:
Search
Copy
Archive
Navigate
Para cada entidad:
- Buscarla
- Copiar/duplicarla
- Archivar/soft delete
- Navegar hacia/desde ella
Oráculos: Cómo Saber Si Algo Está Mal
Un oráculo es un principio o mecanismo para reconocer un problema.
Oráculos comunes:
1. Oráculo de especificación:
Comparar comportamiento con requisitos documentados.
Problema: Especificaciones pueden estar equivocadas o incompletas.
2. Oráculo de producto comparable:
Comparar con competidor o versión previa.
Ejemplo: "Gmail permite adjuntos de 25MB, nosotros también deberíamos"
3. Oráculo de consistencia:
Esperar que cosas similares se comporten similarmente.
Ejemplo: Si Guardar es Ctrl+S en un diálogo, debería ser en todos lados.
4. Oráculo de historia:
Esto funcionó antes, así que debería seguir funcionando.
Ejemplo: Regression testing usa este oráculo.
5. Oráculo de expectativas de usuario:
¿Qué esperaría un usuario razonable?
Ejemplo: Hacer clic en X debería cerrar ventana.
6. Oráculo de estatutos y estándares:
Requisitos legales, estándares de industria (WCAG, GDPR, etc.)
Ejemplo: Debe cumplir estándares de accesibilidad.
Documentando Exploratory Testing
¿Por Qué Documentar?
Beneficios:
- Permite compartir conocimiento
- Proporciona evidencia de testing
- Soporta reproducción de bugs
- Identifica brechas de cobertura
- Facilita hand-offs
- Crea repositorio de aprendizaje
Qué Documentar
Documentación mínima viable:
1. Charter/Objetivo
2. Qué fue probado
3. Qué fue encontrado
4. Qué no fue probado
5. Preguntas levantadas
Documentación completa:
1. Detalles de sesión (fecha, hora, duración, tester)
2. Charter
3. Áreas de prueba y cobertura
4. Datos de prueba usados
5. Detalles de entorno
6. Observaciones y notas
7. Bugs encontrados (con IDs)
8. Preguntas e ideas
9. Riesgos identificados
10. Charters de seguimiento
Formatos de Documentación
1. Mapas Mentales
Visualizar rutas de exploración y hallazgos.
Nodo central: Característica/área siendo probada
Ramas: Diferentes aspectos probados
Hojas: Pruebas específicas y hallazgos
Herramientas: XMind, MindMeister, FreeMind
Ejemplo de estructura:
Procesamiento de Pago
/ | \
Válido Inválido Casos Edge
/ | \
Visa,MC,Amex Formato $0, Negativo
| | |
¡Funciona! Buenos errors ¡BUG!
2. Hojas de Sesión
Plantilla estructurada para toma de notas.
MISIÓN: [Charter]
HORA DE INICIO: [Hora]
DURACIÓN: [Minutos]
TESTER: [Nombre]
NOTAS:
[Hora] - [Acción tomada]
[Hora] - [Observación]
[Hora] - [Bug encontrado]
BUGS: [Lista con IDs]
PREGUNTAS: [Items abiertos]
COBERTURA: [Qué fue/no fue probado]
3. Grabaciones de Pantalla
Grabar sesiones de exploración.
Beneficios:
- Registro completo
- Reproducción de bugs
- Material de entrenamiento
- Revisión y aprendizaje
Herramientas: OBS, Loom, SnagIt, Camtasia
Cuándo grabar:
✓ Security testing
✓ Reproducción de bug compleja
✓ Entrenamiento de nuevos testers
✓ Cuando stakeholders quieren ver testing
✗ Cada sesión (demasiados datos)
4. Screenshots Anotados
Reportes visuales de bugs y notas.
Herramientas: Snagit, Skitch, Annotate, CloudApp
Incluir:
- Flechas apuntando a issues
- Anotaciones de texto
- Cajas rojas alrededor de problemas
- Pasos para reproducir
- Esperado vs actual
5. Notas de Prueba en Código
Para testing técnico, documentar en comentarios o docs.
Ejemplo:
/*
* SESIÓN DE PRUEBA EXPLORATORIA: Autenticación API
* Fecha: 2025-09-30
* Charter: Probar casos edge de JWT token
*
* Hallazgos:
* - Tokens expirados correctamente rechazados
* - Tokens malformados manejados graciosamente
* - BUG: Token con payload modificado aceptado (BUG-456)
*
* No probado:
* - Flujo de refresh de token
* - Sesiones concurrentes
*/
Checklists de Exploratory Testing
Checklist Pre-Sesión
Entorno:
- [ ] Entorno de prueba accesible
- [ ] Datos de prueba disponibles
- [ ] Herramientas listas (navegador, debugger, etc.)
- [ ] Estado limpio (o estado conocido)
Preparación:
- [ ] Charter definido
- [ ] Tiempo asignado
- [ ] Interrupciones minimizadas
- [ ] Plantilla de documentación lista
Conocimiento:
- [ ] Cambios recientes entendidos
- [ ] Requisitos revisados
- [ ] Bugs previos revisados
- [ ] Personas de usuario en mente
Checklist Durante Sesión
Testing:
- [ ] Siguiendo charter ligeramente
- [ ] Tomando notas mientras avanzas
- [ ] Notando patrones
- [ ] Siguiendo corazonadas
- [ ] Cuestionando suposiciones
- [ ] Registrando bugs inmediatamente
- [ ] Tomando screenshots de issues
Mentalidad:
- [ ] Permaneciendo curioso
- [ ] Preguntando "¿qué pasaría si?"
- [ ] Siendo escéptico
- [ ] Pensando como usuario
- [ ] Pensando como atacante
- [ ] Notando inconsistencias
Checklist Post-Sesión
Documentación:
- [ ] Notas de sesión completadas
- [ ] Bugs registrados con detalles
- [ ] Screenshots adjuntados
- [ ] Preguntas documentadas
- [ ] Cobertura notada
Seguimiento:
- [ ] Nuevos charters identificados
- [ ] Stakeholders informados
- [ ] Bugs críticos escalados
- [ ] Lecciones aprendidas capturadas
Housekeeping:
- [ ] Datos de prueba limpiados (si es necesario)
- [ ] Entorno reseteado (si es necesario)
- [ ] Herramientas cerradas
- [ ] Métricas actualizadas
Checklist General de Heurísticas de Testing
Variaciones:
- [ ] Probado con diferentes datos
- [ ] Probado con diferentes usuarios
- [ ] Probado en diferentes estados
- [ ] Probado en diferentes plataformas
Límites:
- [ ] Valores mínimos
- [ ] Valores máximos
- [ ] Vacío/null
- [ ] Primero/último
Errores:
- [ ] Entradas inválidas
- [ ] Entradas faltantes
- [ ] Secuencia incorrecta
- [ ] Interrupciones
Rendimiento:
- [ ] Grandes conjuntos de datos
- [ ] Conexiones lentas
- [ ] Operaciones de larga ejecución
- [ ] Usuarios concurrentes
Seguridad:
- [ ] Intentos de bypass de autenticación
- [ ] Violaciones de autorización
- [ ] Inyección de entrada
- [ ] Exposición de datos
Mejores Prácticas para Exploratory Testing
1. Balancear Estructura y Libertad
✓ Tener un charter, pero no ser rígido
✓ Tomar notas, pero no detener exploración
✓ Seguir corazonadas, pero rastrear cobertura
✓ Ser creativo, pero permanecer enfocado
2. Pensar Como Múltiples Personas
Probar como:
- Un nuevo usuario (confundido, siguiendo tutoriales)
- Un usuario experto (atajos de teclado, características power)
- Un usuario malicioso (intentando romper seguridad)
- Un usuario descuidado (haciendo clic sin leer)
- Un stakeholder de negocio (¿valor entregado?)
3. Pair Exploratory Testing
Beneficios:
- Dos perspectivas
- Discusión en tiempo real
- Uno prueba, otro documenta
- Compartir conocimiento
- Más bugs encontrados
Roles:
- Driver: Controla teclado/mouse, ejecuta pruebas
- Navigator: Sugiere ideas, toma notas, cuestiona
Cambiar roles cada 20-30 minutos
4. Usar Herramientas para Amplificar Testing
Herramientas esenciales:
- Developer tools (Chrome DevTools, Firefox Dev Tools)
- Proxy tools (Charles, Fiddler, Burp Suite)
- Screenshot tools (Snagit, ShareX)
- Note-taking (Evernote, Notion, editores markdown)
- Screen recording (OBS, Loom)
- Generadores de datos de prueba
- Herramientas de mapas mentales
5. Aprender Continuamente
Después de cada sesión:
✓ ¿Qué aprendiste sobre el producto?
✓ ¿Qué aprendiste sobre testing?
✓ ¿Qué harías diferente?
✓ ¿Qué nuevas preguntas emergieron?
✓ ¿Qué patrones notaste?
6. Rastrear y Reportar Valor
Métricas que importan:
- Bugs encontrados (especialmente críticos)
- Preguntas respondidas
- Riesgos identificados
- Cobertura lograda
- Tiempo invertido
Comunicar:
- Compartir hallazgos interesantes
- Destacar bugs críticos inmediatamente
- Proponer nuevos charters basados en descubrimientos
- Educar al equipo sobre lo que aprendiste
7. Alternar Enfoques
Variar tu enfoque de testing:
- Lunes: Basado en tours
- Martes: Enfocado en heurísticas
- Miércoles: Impulsado por persona
- Jueves: Enfocado en integración
- Viernes: Creativo/experimental
Previene:
- Visión de túnel de testing
- Aburrimiento
- Rendimientos decrecientes
Errores Comunes y Cómo Evitarlos
Error 1: Vagabundeo Sin Rumbo
Problema: “Solo estoy haciendo clic sin propósito.”
Solución:
- Siempre comenzar con un charter
- Establecer un temporizador
- Tener una pregunta de foco
- Usar tours como estructura
Error 2: No Documentar
Problema: “Encontré bugs pero no los escribí.”
Solución:
- Documentar mientras avanzas, no al final
- Usar plantillas para hacerlo rápido
- Tomar screenshots inmediatamente
- Grabar notas por voz si escribir es lento
Error 3: Testing Superficial
Problema: “Solo probé caminos felices.”
Solución:
- Usar heurísticas para guiar testing más profundo
- Preguntar “¿qué podría salir mal?”
- Probar casos de error explícitamente
- Seguir el tour de Saboteador
Error 4: Ignorar Contexto
Problema: “Encontré un bug que en realidad es comportamiento esperado.”
Solución:
- Entender requisitos primero
- Hacer preguntas antes de reportar
- Conocer tus oráculos
- Considerar intención del usuario
Error 5: No Rastrear Tiempo
Problema: “Gasté 4 horas en una cosa.”
Solución:
- Usar time-boxes
- Establecer alarmas
- Rastrear tiempo gastado
- Avanzar cuando rendimientos decrecientes
Error 6: Testing en Aislamiento
Problema: “Nadie sabe qué estoy probando.”
Solución:
- Compartir planes de sesión
- Debrief regularmente
- Reportar hallazgos rápidamente
- Colaborar con desarrolladores
Conclusión
El exploratory testing es tanto un arte como una habilidad. Requiere:
- Curiosidad para hacer preguntas
- Escepticismo para cuestionar suposiciones
- Creatividad para imaginar escenarios
- Disciplina para documentar hallazgos
- Adaptabilidad para cambiar dirección
- Intuición desarrollada a través de experiencia
La belleza del exploratory testing es que escala con tu habilidad—un tester junior siguiendo tours y heurísticas encontrará bugs, mientras que un tester experto con profundo conocimiento del producto encontrará issues críticos y sutiles que los tests con script nunca capturarían.
Comienza pequeño:
- Ejecuta una sesión de 60 minutos con un charter claro
- Usa un tour o heurística como guía
- Documenta lo que encuentres
- Aprende de la experiencia
- Repite, mejora, refina
Con el tiempo, desarrollarás un instinto para donde se esconden los bugs, qué preguntas hacer y cómo hacer que cada minuto de testing cuente.
Recuerda: El exploratory testing no reemplaza el scripted testing—lo complementa. Usa ambos enfoques estratégicamente para construir cobertura de pruebas completa que sea tanto sistemática como perspicaz.
Lecturas Adicionales
- “Explore It!” de Elisabeth Hendrickson
- “Lessons Learned in Software Testing” de Cem Kaner, James Bach, Bret Pettichord
- “Testing Computer Software” de Cem Kaner
- Blog de James Bach: satisfice.com
- Blog de Michael Bolton: developsense.com
- Metodología Rapid Software Testing