Cómo hacer pruebas exploratorias de forma profesional (sin caer en el caos)

Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Hoy quiero compartir algo contigo que he visto muchas veces en equipos, incluso en personas con bastante experiencia, y es que cuando se habla de pruebas exploratorias, todos parecen estar de acuerdo en que son importantes… hasta que llega el momento de aplicarlas.

Porque una cosa es entender la idea, y otra muy distinta es sentarte frente a un sistema y decir: “ok, ¿y ahora cómo exploro esto sin perderme?”. Y estoy seguro que te ha pasado, porque cuando inicie en el mundo de la calidad yo mismo me hice esas preguntas.

Recuerdo proyectos donde se decía “explora un poco esto”, pero en realidad nadie te explicaba qué significaba eso. Entonces hacías lo que podías: probabas algunas cosas, movías datos, revisabas respuestas… pero al final te quedaba esa sensación de que no sabías si realmente habías hecho un buen trabajo o solo habías estado navegando sin rumbo. Y claro, cuando eso pasa varias veces, es fácil caer en una conclusión peligrosa: pensar que explorar no es serio.

Con el tiempo entendí que para poder hacer una buena sesion de exploratory testing habia que darle estructura.

Y aquí quiero aclarar algo importante, porque suele haber mucha confusión con esto. Cuando hablo de estructura, no me refiero a convertir la exploración en un test case con diez pasos. No se trata de quitarle flexibilidad. Se trata de darle suficiente intención como para que genere valor. Porque sí, la idea sigue siendo explorar con libertad… pero no sin dirección.

Hay algo que cambió completamente mi forma de ver esto: Dejar de pensar en la exploración como “probar cosas” y empezar a verla como una conversación con el sistema.

Cada acción que haces es una pregunta y entonces cada respuesta del sistema es información. Y lo que haces después depende de qué tan bien estés escuchando.

Por ejemplo, me pasó en un proyecto donde estábamos trabajando con un servicio que procesaba información. Todo parecía funcionar bien en los escenarios esperados. Los test cases pasaban, los flujos principales estaban cubiertos y el equipo estaba bastante tranquilo.

Pero había algo que no terminaba de convencerme. Así que decidí tomarme un rato para explorar, pero esta vez con más intención. No era solo “probar a ver qué pasa”, sino tratar de entender mejor cómo respondía el sistema cuando lo sacabas de su zona cómoda. Empecé con algo simple: cambiar los datos de entrada, primero valores normales y todo bien. Luego valores vacíos con esto encontré algunas respuestas raras, y después valores más largos de lo habitual… y ahí empezó a ponerse interesante.

El sistema no fallaba como tal, pero se volvía más lento. No era algo que ibas a ver en un caso de prueba típico, porque nadie había definido ese escenario como crítico.

Pero en producción, eso podía escalar, y ese tipo de hallazgos son los que muchas veces marcan la diferencia. No porque estés buscando errores al azar, sino porque estás explorando con intención.

A partir de experiencias como esa, empecé a usar algo muy simple para no perderme cuando exploro. No es una plantilla rígida, ni algo complicado. Es más bien una guía mental que me ayuda a mantener foco.

Y quiero compartirla contigo porque creo que te puede servir muchísimo.

Primero, antes de empezar, me hago una pregunta muy sencilla:

¿Qué quiero aprender aquí?

No tiene que ser perfecto. A veces es algo tan simple como “quiero entender cómo maneja errores este flujo” o “quiero ver cómo responde este endpoint con datos raros”. Pero tener esa intención cambia todo.

Luego viene algo que, para mí, es clave:

¿Qué me preocupa?

Porque no es lo mismo explorar por curiosidad que explorar con un riesgo en mente. Tal vez te preocupa que las validaciones no sean suficientes. O que los mensajes no sean claros, o que el sistema no escale bien.

Cuando tienes eso claro, dejas de moverte sin rumbo y empiezas a investigar, y espués viene la parte más interesante.

¿Qué puedo cambiar aquí?

Y aquí es donde realmente empieza la exploración. Empiezas a jugar con cosas como: datos vacíos, valores extremos, combinaciones raras, caracteres especiales, uno, cero o muchos elementos…

No es aleatorio. Es intencional, porque estás moviendo piezas para ver cómo reacciona el sistema.

Mientras haces esto, hay algo que no puedes perder:

La observación.

Porque explorar no es solo hacer acciones. Es prestar atención. A veces el sistema no falla de forma evidente, responde más lento, devuelve algo que “funciona”, pero no tiene sentido. Y ahí es donde tienes que detenerte y pensar: “esto es normal… o hay algo más aquí?”

Y finalmente, algo que antes no hacía y ahora considero clave: decidir qué hacer con lo que encontré, porque no todo termina en un bug, aveces es una conversación con el equipo, o una mejora en los criterios, una idea para un nuevo test case, y con esto logras conectar la exploración con el resto de tu sistema de pruebas.

Con el tiempo me di cuenta de algo que me hubiera gustado entender antes: Las pruebas exploratorias generan claridad y te ayudan a entender el sistema de una forma que no logras solo siguiendo pasos. Te obligan a pensar, a cuestionar y a ver más allá de lo evidente.

Así que si te tengo que dejar una recomendación después de todo esto, sería esta: no intentes hacerlo perfecto. La próxima vez que tengas la oportunidad de explorar, empieza simple. Define qué quieres aprender, mueve algunas variables con intención, observa con atención y reflexiona sobre lo que encuentres. Poco a poco vas a notar que ya no te sientes perdido, y más importante aún, vas a empezar a confiar más en tu criterio. Y con este llegamos al final de esta seria de tres blogs sobre test exploratorios. Me gustaria saber si te han servido para algo y me lo dejes saber en los comentarios, yq ue por supuesto los compartas con cualquiera que esté en el mundo de la calidad. Saludos y nos vemos el proximo lunes.

📥 Guía rápida que puedes usar desde hoy

Si quieres algo práctico para comenzar, puedes apoyarte en esto:

  1. ¿Qué quiero aprender?
  2. ¿Qué me preocupa?
  3. ¿Qué voy a cambiar?
  4. ¿Qué estoy observando?
  5. ¿Qué hago con esto?

No necesitas más que eso para empezar a explorar con intención.

Leave a Reply

Your email address will not be published. Required fields are marked *