¿Qué es eso del testing exploratorio? ¿Y para qué me sirve?

Puede hayas oído hablar de este “tipo” de testing, sobre todo en entornos ágiles. E incluso, puede que lo identifiques con probar ad-hoc, sin planificación alguna, sin límite de tiempo, sin documentación.

Pero el testing exploratorio bien hecho no es eso.

Con este post entenderás de forma sencilla qué es el testing exploratorio y cuándo y para qué puede utilizarse.
—-
El testing exploratorio es un enfoque de testing en el que simultáneamente se aprende sobre la aplicación, se diseñan casos de prueba y se ejecutan esos casos de prueba.

Es decir, cuando una persona hace testing exploratorio, diseña y ejecuta pruebas con un objetivo en concreto.

Con las conclusiones que obtiene va aprendiendo sobre la aplicación, y utiliza esa información para diseñar y ejecutar nuevas pruebas.

Cuando hacemos testing exploratorio no probamos por probar, sino que antes de empezar tenemos que definir varias cosas:

1 – Un objetivo que queremos conseguir con la sesión de testing exploratorio (por ejemplo establecer flujos que podrían seguir los usuarios de la aplicación y probarlos, ver cómo se integra la aplicación con software externo, vulnerabilidades de seguridad en el login etc.), que puede ponerlo el propio tester, el equipo de testing, o el test manager

2 – Limitar de alguna manera el tiempo que vamos a dedicarle a esa actividad de testing (sesiones de 1 hora, 25 min etc.).

Como ves limitamos qué queremos conseguir en cuánto tiempo, pero el objetivo es bastante general, no se indica qué pasos debe ir verificando el tester. El tester es el responsable del camino que debe seguir para conseguir ese objetivo, que puede ir cambiando a medida que va aprendiendo sobre la aplicación durante el tiempo establecido.

Por ello, para hacer buenas pruebas exploratorias, es necesario que los testers tengan una mente abierta, pensamiento crítico, sean observadores, creativos, y curiosos para detectar bugs más complejos y evaluar riesgos.

El testing exploratorio bien planteado puede dar muy buenos resultados, pero todo depende de las habilidades del tester, de que sea capaz de analizar en qué puntos podría fallar la aplicación (de acuerdo al objetivo establecido), qué riesgos puede tener eso etc.; todo ello basándose en el conocimiento que tiene de la aplicación.

Esto requiere mayor actividad intelectual y experiencia que verificar funcionalidades, pero por experiencia, suele motivar más a los testers experimentados, ya que pone a prueba sus habilidades, es un reto.

Normalmente los bugs que se encuentran durante el tiempo que dediquemos a hacer testing exploratorio se reportarán al final.

Y testing exploratorio no equivale a no documentar: podemos documentar el objetivo de la sesión de testing exploratorio, bocetos de los casos de prueba que vayamos realizado, diagramas etc. Podemos ayudarnos de documentar en Word, Excel, capturas de pantalla etc.

No hay ninguna restricción sobre cómo documentar en testing exploratorio, pero si que veo recomendable documentar, aunque no realizar una documentación exhaustiva (al menos, en lo que dura la sesión, ya que solamente diseñar casos de prueba no es el objetivo).

Lo que si es imprescindible (como en cualquier actividad de testing) es ser capaces de reproducir los bugs que encontremos.
Aunque vayamos aprendiendo, diseñando y ejecutando test, el proceso de testing debe ser fiable.

De hecho, la idea es que a medida que avanza la sesión de testing exploratorio aumente la calidad de las pruebas que haces (en relación al objetivo que quieres cumplir), ya que aprendes sobre la aplicación y vas alimentando el diseño y ejecución de tus pruebas con lo que vas aprendiendo.

 ¿Y para qué sirve el testing exploratorio?

Personalmente recomiendo que no solo realicemos testing exploratorio, sino que esto sea una actividad complementaria al testeo de funcionalidades, historias de usuario, pruebas automatizadas etc. En definitiva, algo complementario al resto de nuestras actividades de testing, que realicemos de manera puntual.

Si que es bastante bueno si necesitamos:

– Profundizar y obtener feedback rápido sobre algo concreto.
– Aprender sobre la aplicación.
– Si ya cubres una parte del testing con automatización, testeo y verificación manual de funcionalidades etc. y quieres buscar bugs más complejos.
– Mejorar la documentación de la aplicación, de los casos de prueba o los scripts de automatización (ya que podemos usar la experiencia adquirida para mejorar la documentación de la aplicación, de los casos de prueba etc.)

Si que es cierto que no tiene mucho retorno de inversión en aplicaciones críticas, en entornos muy estables, donde se tiene muchísimo conocimiento de la aplicación.

Terminando…

El testing exploratorio requiere su planificación, limitación de tiempo y objetivo, no está reñido con documentar y hacerlo bien es más complicado.

Pero como todo en esta vida: no nos convertimos en cinturones negros de karate sin hacer nada, tenemos que practicar.

En mi caso, para lo que más lo he empleado es para aprender sobre la aplicación, y buscar bugs complejos.

Al final motivamos a los testers a que utilicen su intuición, ideas nuevas, su habilidad crítica, para detectar bugs más complejos. Y practican, mejoran como testers.

Si lo pruebas, te sorprenderás con los resultados.

3 comentarios en “¿Qué es eso del testing exploratorio? ¿Y para qué me sirve?”

  1. Son un fantastico complemento a la automatización de pruebas. Una buena estrategia es centrar las sesiones en características del sistema que aporten mayor valor al usuario.
    Y en lo que mencionas de la importancia de la documentación y registro de las pruebas recordar que el objetivo de estas es aportar información a cerca de la aplicación. Si no las tenemos registradas no tenemos esa información.

  2. A los puntos 1 y 2 me gustaría añadir..
    3. Una vez finalizada la sesión, comparte tus notas. Con los developers, con otros testers, con el test lead. Explica qué has testeado, qué te ha llamado la atención, que te ha sorprendido y porqué.
    No te limites a reportar bugs, aprovecha el debriefing para aprender sobre tus pasos y comparte.
    4. Si además mides el tiempo que le dedicas a S – Setup, T – Testing y B – Bug reporting, verás que cuanto más BS, menos T puedes hacer. Esta medida del tiempo ayuda a comprender el riesgo de dejar de testear un área o una funcionalidad.

    Y para terminar, recordad que del testing exploratorio obtenemos distintos resultados que del testing automatizado.
    Que automatizamos para repetir, asegurar y obtener feedback en poco tiempo,
    Y exploramos para aprender, modelar, comprender, y dejar que las casualidades ocurran.

    Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba