Pruebas exploratorias: cuando el script no encuentra el bug raro

La respuesta corta: las pruebas exploratorias sirven para encontrar los defectos que tu suite automatizada nunca buscará, porque un guion solo comprueba lo que su autor ya imaginó. Explorar es diseñar la prueba, ejecutarla y aprender de ella al mismo tiempo, con un humano decidiendo el siguiente paso según lo que acaba de ver. No es clickear al azar: es una disciplina con carta de misión, tiempo acotado y evidencia.

Hay una confusión que cuesta dinero. Mucha gente cree que "automatizamos todo" equivale a "probamos todo". No. La automatización es excelente para repetir lo conocido y protegerte de regresiones. Pero un caso automatizado nace de una hipótesis que ya tenías. El bug que te tumba producción un viernes suele vivir justo fuera de esa hipótesis, en la esquina que a nadie se le ocurrió escribir.

01 · el punto ciegoPor qué el script no ve el bug raro

Un script hace una cosa maravillosa y una cosa peligrosa. La maravillosa: ejecuta el mismo camino mil veces sin cansarse y grita si algo cambia. La peligrosa: nunca se sale de ese camino. Si el defecto está en un estado que nadie modeló, el script pasa por al lado sin verlo, en verde, dándote una falsa sensación de cobertura.

El estándar ISO/IEC/IEEE 29119 lo reconoce de forma explícita: el testing basado en scripts y el testing exploratorio son enfoques complementarios, no rivales. Uno documenta y repite; el otro descubre. Renunciar al segundo porque tienes el primero es como revisar una casa solo por los pasillos que ya barriste.

Un caso automatizado solo puede fallar por la razón que su autor ya imaginó.

El testing exploratorio ataca ese punto ciego con una idea simple: el mejor detector de rarezas que existe sigue siendo una persona con criterio observando el sistema en vivo. Cuando ves un parpadeo raro, un total que no cuadra por un centavo o un botón que responde tarde, tu cabeza formula una hipótesis nueva al instante y la pruebas. Ese bucle de aprender-mientras-pruebas es lo que ningún guion fijo puede hacer por ti.

02 · la disciplinaNo es clickear al azar: cartas, tiempo y sesiones

Aquí está el malentendido que hay que enterrar. Testing exploratorio no significa "toca cosas a ver qué pasa". Significa aprendizaje, diseño y ejecución de pruebas de forma simultánea, guiada por un objetivo. La diferencia entre un explorador y alguien que clickea al azar es la misma que entre un detective y un curioso: ambos miran, pero solo uno sigue una línea de investigación.

La forma madura de esta práctica se llama Session-Based Test Management (SBTM), propuesta por Jonathan y James Bach a comienzos de los 2000 para dar estructura y rendición de cuentas sin matar la libertad de explorar. Tres piezas la sostienen:

La carta de misión (charter). Antes de tocar nada, escribes en una o dos frases qué vas a explorar y por qué. Por ejemplo: "explorar el flujo de checkout con cupones vencidos para descubrir problemas de cálculo del total". La carta enfoca sin encadenar; te dice dónde cazar, no cómo.

El tiempo acotado (time-boxing). La exploración ocurre en sesiones ininterrumpidas de entre 60 y 120 minutos. El límite protege el foco y hace que el esfuerzo sea medible. Una sesión no es "toda la tarde a ver qué sale"; es un bloque con inicio, fin y una misión concreta.

La bitácora (session report). Durante la sesión anotas qué probaste, qué encontraste, qué preguntas te surgieron y cuánto tiempo se fue en probar frente a investigar bugs o preparar el entorno. Esa bitácora convierte una actividad que parece improvisada en algo revisable, repetible y presentable ante cualquiera.

03 · el equilibrioComplemento del humano a la automatización

La pregunta correcta no es "automatizar o explorar", sino "qué le toca a cada uno". La automatización cubre lo que ya sabes que debe seguir funcionando: regresiones, humo, caminos felices críticos, validaciones repetitivas. La exploración cubre lo que aún no sabes: comportamientos emergentes, combinaciones raras de estado, problemas de usabilidad que ningún assert detecta.

Hay algo que la exploración exige y que conviene nombrar: un oráculo, es decir, un criterio para decidir si lo que ves está bien o mal. En un caso automatizado el oráculo está congelado en el código. En la exploración el oráculo vive en la cabeza del tester, alimentado por la especificación, la coherencia interna del producto y la experiencia. Por eso esta disciplina depende tanto del criterio de quien la ejecuta.

La calidad, entendida como la define la ISO/IEC 25010 en atributos como funcionalidad, usabilidad y fiabilidad, no se agota en "los asserts pasan". Un total que cuadra pero un flujo que confunde al usuario es un producto que pasa los tests y falla a la persona. Esa clase de defecto casi siempre lo encuentra alguien explorando, no un guion.

Automatiza lo que ya entiendes; explora para entender lo que aún no.

En la práctica, un equipo sano hace las dos cosas y las conecta. Cuando una sesión exploratoria descubre un bug raro y valioso, ese hallazgo se convierte después en un caso automatizado que vigila esa esquina para siempre. Así la exploración alimenta a la automatización: el humano descubre el territorio nuevo, y el script lo defiende una vez conocido.

La conclusión es directa. Si tu estrategia de calidad solo tiene scripts, estás protegido contra los errores que ya imaginaste y ciego ante los que no. Añade exploración gobernada, con cartas, tiempo acotado y bitácoras, y le das a tu producto lo único que ninguna máquina te da todavía: una mente curiosa buscando el problema que a nadie se le había ocurrido.