Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Si hay un tema que sigo viendo mal entendido en muchos equipos, incluso en personas que ya tienen tiempo trabajando en testing, es el de las pruebas exploratorias. Y lo digo porque todavía escucho frases como: “haz unas pruebas exploratorias ahí rapidito mientras llegan los test cases” o “eso es probar sin estructura, ¿no?”. Cada vez que escucho algo así, siento que seguimos arrastrando una idea muy limitada de lo que realmente significa explorar un sistema.

Durante años se ha construido una percepción peligrosa alrededor de este tipo de pruebas. Mucha gente las ve como algo informal, desordenado o incluso improvisado, casi como si fueran el plan B cuando no hubo tiempo de hacer testing “de verdad”. Y justamente ahí es donde está el problema, porque se termina subestimando una práctica que, bien ejecutada, puede ayudarte a entender el sistema mucho mejor que una lista rígida de pasos.

¿Por qué muchas personas creen que explorar es improvisar?

Creo que una de las razones principales es que estamos demasiado acostumbrados a asociar el testing formal con documentos visibles. Cuando alguien piensa en una prueba “seria”, imagina casos de prueba escritos, pasos definidos, datos preestablecidos y resultados esperados. Y por supuesto, todo eso tiene valor. No voy a decir que no, porque sí lo tiene. El problema aparece cuando creemos que esa es la única forma válida de probar.

Un test case normalmente te dice qué verificar, pero no siempre te ayuda a descubrir lo que nadie pensó verificar. Y en productos reales, sobre todo cuando el negocio cambia rápido, cuando las reglas no están tan claras o cuando la funcionalidad todavía se está entendiendo, esa capacidad de descubrir se vuelve muy valiosa. Ahí es donde el testing exploratorio deja de ser un complemento y se convierte en una herramienta muy seria de aprendizaje.

Entonces, ¿explorar es hacer cosas al azar?

Por supuesto que no. Explorar no es hacer clics sin sentido ni moverse por una aplicación esperando que algo extraño ocurra por accidente. Explorar bien significa tomar decisiones conscientes en tiempo real, apoyándote en lo que vas observando y aprendiendo del sistema mientras lo pruebas. Y eso, lejos de requerir menos pensamiento, exige mucho más criterio.

Cuando una persona hace pruebas exploratorias de forma madura, no está “probando por probar”. Está observando cómo se comporta la aplicación, identificando variables interesantes, detectando patrones, cambiando datos, comparando respuestas y generando nuevas ideas en función de lo que acaba de descubrir. En otras palabras, está diseñando pruebas en vivo. Tal vez no con un guion rígido de diez pasos, pero sí con una intención clara y con una lógica detrás de cada decisión.

¿Por qué entonces algunas sesiones exploratorias sí se ven desordenadas?

Porque muchas veces a las personas nunca les enseñaron a hacerlas bien. Y cuando eso pasa, lo que se llama “prueba exploratoria” termina siendo una sesión de clics sin propósito, sin objetivo, sin foco y sin forma clara de explicar qué se hizo o por qué se hizo. Allí es cuando aparecen los clásicos problemas: se prueba sin intención, los hallazgos quedan mal explicados, no hay trazabilidad y luego alguien concluye que explorar es improvisar.

Pero el problema no es la exploración. El problema es no darle estructura suficiente. Y aquí quiero aclarar algo importante: estructura no significa rigidez. Uno de los errores más comunes es pensar que si no existe un script paso a paso, entonces no existe método. Y no es así. Las pruebas exploratorias también tienen estructura, solo que es una estructura más flexible y más basada en pensamiento crítico.

¿Qué estructura debería tener una buena prueba exploratoria?

Aunque no tengas un caso de prueba detallado, hay algunos elementos que no deberían faltar. El primero es un objetivo claro. No empiezas a explorar simplemente porque sí. Empiezas porque quieres aprender algo, entender un comportamiento o investigar un riesgo. A veces ese objetivo puede sonar tan sencillo como “quiero entender cómo este flujo maneja errores” o “voy a observar qué pasa cuando envío datos inesperados”. Lo importante no es memorizar el término charter, aunque en muchos libros se hable de eso. Lo importante es que tengas claro qué estás buscando y por qué.

El segundo elemento tiene que ver con las variables que decides cambiar. Aquí está una de las partes más potentes del testing exploratorio, porque en lugar de seguir pasos cerrados, comienzas a pensar en términos de variación. ¿Qué pasa si dejo el campo vacío? ¿Qué ocurre si envío un valor muy largo? ¿Y si uso caracteres especiales? ¿Y si hago la operación con uno, cero o muchos elementos? Este tipo de pensamiento te obliga a mirar el sistema con curiosidad, pero también con intención. No se trata de probar por accidente, sino de mover variables de manera estratégica para observar cómo responde la aplicación.

El tercer elemento es el aprendizaje continuo. Cada acción que realizas te devuelve información, y esa información debería influir en el siguiente paso. Si algo falla, profundizas. Si algo tarda demasiado, empiezas a pensar en performance. Si una respuesta no es clara, cuestionas el diseño o incluso los criterios de aceptación. Y aquí es donde, desde mi punto de vista, se nota la diferencia entre alguien que simplemente ejecuta pruebas y alguien que realmente está entendiendo el producto.

¿Dónde quedan entonces los test cases?

Aquí es donde muchas personas se enredan, porque creen que hay que elegir entre test cases o exploración, como si una cosa excluyera a la otra. Pero en la práctica, cumplen propósitos distintos. Los test cases ayudan a verificar, a dar cobertura y a asegurar repetibilidad. Las pruebas exploratorias, en cambio, ayudan a descubrir, a reducir riesgos y a revelar comportamientos inesperados.

De hecho, en muchos proyectos las mejores ideas para nuevos test cases nacen justamente de una buena sesión exploratoria. Primero descubres algo interesante, entiendes el riesgo y luego decides que vale la pena convertir ese aprendizaje en una verificación más repetible. Por eso, en lugar de ver ambas prácticas como opuestas, yo las veo como complementarias.

¿Por qué seguimos subestimando este tipo de pruebas?

Porque son más difíciles de medir con las herramientas tradicionales. Porque no siempre encajan bien en una hoja de Excel. Porque desde afuera parecen menos ordenadas que una tabla llena de pasos y resultados esperados. Y sin embargo, si algo he visto en proyectos reales es que los errores más importantes rara vez aparecen en los pasos 1, 2 y 3 de un caso de prueba ya conocido. Muchas veces aparecen cuando alguien se detiene, observa un poco más y se pregunta: “¿qué pasa si hago esto de una forma distinta?”.

Ese tipo de pensamiento no surge solo por tener experiencia, sino por darte permiso de investigar con criterio. Y ese permiso, en muchos equipos, todavía no se da con suficiente frecuencia.

Mi recomendación para ti

La próxima vez que alguien te diga “haz pruebas exploratorias mientras tanto”, no lo tomes como una tarea de relleno. Tómalo como una oportunidad real de entendimiento. Comienza definiendo qué quieres aprender, decide qué variables vas a mover, presta atención a lo que el sistema te devuelve y usa esa información para profundizar. No explores para llenar tiempo. Explora para entender.

Porque al final, la diferencia no está en si tienes o no un script. La diferencia está en cómo piensas cuando pruebas, y en qué tan dispuesto estás a dejar que el sistema te muestre cosas que nadie había previsto.

---

📥 Recurso práctico

Mini plantilla para una sesión de pruebas exploratorias

Plantilla rápida de sesión exploratoria

1. Objetivo de la sesión

¿Qué quiero aprender o investigar?

Ejemplo: entender cómo el sistema maneja errores al registrar usuarios.

2. Riesgo o área de interés

¿Qué me preocupa aquí?

Ejemplo: validación de campos, mensajes confusos, datos inesperados.

3. Variables que voy a cambiar

¿Qué cosas puedo variar intencionalmente?

Ejemplo: campos vacíos, longitud extrema, caracteres especiales, combinaciones inválidas.

4. Qué observé

¿Qué comportamientos llamaron mi atención?

¿Qué fue distinto a lo esperado?

¿Qué dudas aparecieron?

5. Próximos pasos

¿Esto merece un bug, una conversación, un nuevo test case o una revisión del criterio?