Las pruebas exploratorias son un enfoque de testing que funciona como aliado perfecto para el ritmo de trabajo de un equipo ágil. ¡Conoce más en este post!

El testing exploratorio (Exploratory Testing en inglés) es un enfoque para la realización de pruebas de software, en donde se aprende simultáneamente sobre la aplicación, el diseño de casos de prueba y la ejecución de los mismos, según señala Javier Garzas, experto en gestión Ágil y equipos Ágiles.

Por esta razón, cuando se dice que una persona realiza testing exploratorio, se entiende que aprende, diseña y ejecuta pruebas con un objetivo en concreto.

En esta entrada, presentamos un enfoque de testing diferente al tradicional, con el objetivo de reconocer su efectividad dentro de un equipo ágil.

¿Qué es Testing Exploratorio?

El testing exploratorio es un enfoque o técnica de prueba muy poderoso, ya que otorga plena libertad de probar y se le considera un aliado perfecto para el ritmo de trabajo de un equipo ágil.

¿Cuándo es recomendable realizar Pruebas Exploratorias?

• Cuando se quiere aprender rápidamente del producto.
• Al proveer feedback de un producto nuevo o de alguna funcionalidad de un producto; en este caso en concreto, probar una historia de usuario.
• Cuando se desea ampliar la cobertura de las pruebas, por ejemplo, si se cubre una parte del testing con casos de pruebas o pruebas automatizadas, es factible buscar bugs o nuevos flujos con este enfoque.
• Para mejorar las pruebas existentes, es posible crear nuevos flujos o  alternativos no considerados en el set de pruebas y mejorar las pruebas obsoletas.
• Es de utilidad en las pruebas de regresión cuando se requieren resultados rápidos y es necesario comprobar que la aplicación y/o el sistema no fue afectado con la última versión subida; el testing exploratorio es apropiado para definir flujos críticos o buscar bugs.

Beneficios del Testing Exploratorio

Al trabajar dentro de un equipo ágil, las principales ventajas son las siguientes:

1. Entregar feedback anticipadamente

No es necesario finalizar el proceso de pruebas para entregar feedback, día a día se pueden ir proponiendo mejoras.

2. Tomar decisiones en tiempo real

Cuando se trabaja en un equipo ágil, es fácil estar al tanto de los cambios o mejoras que se implementarán en el equipo y así poder adaptar internamente las pruebas.

3. Llegar donde la automatización no puede llegar

Los testers pueden pensar como un usuario.

4. Entregar resultados en un menor tiempo

Es posible informar al equipo cómo van las pruebas diariamente, o bien, en el momento que se estime necesario.

Habilidades de un tester para hacer pruebas exploratorias

Para realizar buenas pruebas exploratorias, es necesario que los testers cuenten con las siguientes habilidades:

Vale la pena resaltar que tener un pensamiento out of the box (think outside of the box) es una metáfora que significa pensar diferente, de manera no convencional o desde una nueva perspectiva, lo cual es vital para un tester pues siempre está intentando ir más allá.

Por otro lado, es común escuchar que el testing exploratorio es un enfoque informal, más conocido como testing ad hoc o libre. Sin embargo eso no es del todo cierto, veremos por qué a continuación.

¿En qué consiste el Testing Ad hoc?

Este enfoque de testing consiste en realizar pruebas a las funcionalidades de la aplicación sin planificación alguna, es decir, sin verificar la cobertura, sin límite de tiempo, y sin generar documentación: simplemente se prueba.

Pero entonces, ¿cómo el tester demuestra su trabajo? Siendo el testing ad hoc un enfoque libre que no precisa registrar nada, prácticamente es como si no se hubiera ejecutado nada. Por esta razón, en Abstracta se trabaja de acuerdo a lo propuesto por Jonathan Bach: se utiliza como estrategia de pruebas el testing exploratorio basado en sesiones.

Las sesiones de testing exploratorio surgieron como parte de un trabajo conjunto entre James Bach y Jonathan Bach para reinventar la administración de este tipo de pruebas. De hecho, Jonathan es el creador de las sesiones.

¿Qué es una Sesión de Prueba?

Según el Quality Engineer, doctorado en informática y COO de Abstracta Federico Toledo, quien cuenta más de 10 años de experiencia en Consultoría, Investigación y Desarrollo vinculado al área de Testing, señala en su libro Introducción a las Pruebas de Sistemas de Información que “una sesión es una unidad básica de trabajo dentro de un bloque de tiempo”.

A continuación veremos las particularidades de una sesión de prueba:

Características de una Sesión de Prueba

Ser ininterrumpida

Es muy importante que una sesión sea ininterrumpida y respetar el tiempo acordado; de esta manera existe un enfoque en las pruebas y no se pierde tiempo valioso documentando ni deteniéndose en medio de ellas, tal como ocurre en los casos de pruebas.

Balance entre foco y flexibilidad

Una sesión permite ciertamente ‘irse por las ramas’ y no limitarse a un único objetivo.

Mejora Continua

Los resultados obtenidos durante las sesiones anteriores guiarán las acciones, los pasos y los siguientes escenarios de pruebas a ejecutar, construyendo así un conjunto de pruebas más eficaz.

Test no Guionado

El test no guionado consiste en que se tiene el qué probar y la misión, pero no el cómo hacerlo, ya que no se tienen al alcance documentos o casos de pruebas que indiquen cómo ejecutar las pruebas.

¿Cómo documentar las Sesiones de Prueba?

Primero, para documentar las sesiones de pruebas se puede utilizar papel, una planilla, Jira, Mind Maps haciendo uso de alguna de estas herramientas o un par de post-it. ¡Use el método que más le acomode!

Elementos a documentar en cada Sesión

De acuerdo a la propuesto por Jonathan Bach, una sesión debe contener los siguientes elementos:

Misión

Detallar el propósito de la sesión o como señala Federico, se puede mencionar también algún aspecto o característica específica; según el momento del proyecto se tendrán misiones más generales o más específicas.

Áreas

Definir el entorno en que se realizará la prueba, por ejemplo, un sistema operativo, un navegador, un ambiente de pruebas específico o un repositorio git.

Tiempo de la sesión

Precisar la fecha y hora exacta cuando se da inicio a la sesión.

Testers

Detallar el nombre del tester o los testers que participarán en la sesión de prueba.

División de tareas

Además de ayudar en la interpretación de los resultados de una sesión, el objetivo de la división de tareas es definir cuál será la duración y cómo se distribuye ese tiempo en el equipo. Entonces, ¿cuánto debe durar la sesión?

La duración de una sesión de prueba se clasifica según su extensión:

• Sesión corta (30 a 45 minutos).
• Sesión media (45 a 90 minutos).
• Y Sesión larga (90 a 120 minutos).

Adicionalmente, se debe indicar cómo se distribuye el tiempo entre las siguientes tareas, determinando su porcentaje representativo:

• Diseño y ejecución de pruebas (%X).
• Investigación y reporte de defectos (%X).
• Armado de la sesión (%X).

Finalmente, se tendrá que especificar en % si la misión se centró en el objetivo, o bien, ‘se fue por las ramas’, es decir, se encontraron oportunidades:

• Misión vs. Oportunidad (X % / Y &).

Archivos de datos

Documentos, links con información, credenciales, consultas de bases de datos, mockups y toda información que será de utilidad en la ejecución de las pruebas.

Notas de Pruebas

Las notas son de suma importancia para el tester, pues ahí registra todo lo que se considera importante durante la exploración.

Riesgos

Apuntar todos los riesgos identificados durante la sesión de pruebas.

Defectos

Registrar los identificadores (IDs) o la descripción de los incidentes encontrados.

Inconvenientes

Anotar todo inconveniente o impedimento que haya surgido durante la sesión.

Después de exponer los puntos claves para documentar una sesión, a continuación se muestra el registro de una sesión empleando el enfoque de testing exploratorio ágil.

Ejemplo del registro de una Sesión

En la gráfica se muestra cómo documentar correctamente una sesión, sin embargo, ¿qué se hace con la información recolectada durante las pruebas? La respuesta es simple. Se pueden generar métricas y así brindar más visibilidad al trabajo realizado.

Es decir, al registrar el resultado o los hallazgos de las sesiones, se puede ver cómo van las pruebas ejecutadas y cuáles son las pruebas que deben ser repetidas, en caso de que se hayan encontrado errores o alguna oportunidad que probar.

A continuación, se muestra una tabla explicativa de ejemplo con información detallada de algunas sesiones:

Con base en la gráfica se puede deducir lo siguiente:

• En el test TE-S01, del tiempo propuesto para la sesión se dedicó el 80% del tiempo a verificar y reportar defectos e inconvenientes.

• En el test TE-S02, del tiempo propuesto para la sesión se dedicó el 40% del tiempo a verificar y reportar defectos.

• Por último, del tiempo propuesto para la sesión en el test TE-S03 se dedicó una parte del tiempo para explorar oportunidades.

Conclusiones

Finalmente, vale resaltar que el testing exploratorio es una forma distinta de hacer testing a lo que se conoce, ya que no hay que esperar a que terminen de diseñar las pruebas para luego probar: el tester hace todo al mismo tiempo.

Aquí hay otras conclusiones:

• La efectividad de este tipo de pruebas se basa mucho en las experiencias, ya que un tester ha desarrollado varias habilidades a lo largo de su carrera, pero esto no significa que un junior no pueda hacerlo: si quiere aprender puede hacerlo.
• El principal foco del testing exploratorio es buscar errores o inconvenientes, pues se pueden probar situaciones que aún no están documentadas.
• Los resultados obtenidos permiten definir las siguientes sesiones a realizar, es decir, una mejora Continua.
• El testing exploratorio amplía los conocimientos continuamente, ya que se puede aprender constantemente de la aplicación.
• No existen límites para probar. El tester puede ser libre de testear y determinar hasta dónde puede llegar.
• El cambio de mindset es lo más complicado, ya que es necesario sacar de la cabeza las ideas de un caso de prueba; no hay nada que oriente sobre lo que se debe hacer.

En Abstracta, comenzamos hace un tiempo con las pruebas exploratorias y ha sido una práctica que se ha ido incrementando: toda una experiencia. Pese a que el tema del mindset se fue desarrollando de forma progresiva, seguimos aprendiendo.

---

¿Has realizado testing exploratorio previamente? Si no has tenido la oportunidad, esperamos con este post motivar a poner en práctica lo expuesto y ejecutar una sesión tomando como ejemplo cualquier sitio web. ¡Déjanos un comentario con tu experiencia!

¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y Youtube para ser parte de nuestra comunidad y afianzar tus conocimientos en testing exploratorio en entornos ágiles!

---

Otros contenidos relacionados

Diferencias entre testing funcional y no funcional

Testing Manual vs. Automatizado: ¿cuál elegir para tu proyecto?

Los 7 Principios Esenciales del Testing de Software

Cómo crear la Estrategia de Pruebas adecuada para tu proyecto