Hay una dinámica para compartir la técnica de testing exploratorio que la disfruto muchísimo. Hay quienes la llaman mob testing (en analogía con mob programming) o podríamos considerarlo un testing dojo (en analogía a coding dojo). De cualquier forma, la dinámica trata de poner en práctica el testing exploratorio entre todos los asistentes al curso o taller, ya que no es algo que se termine de comprender solo por escuchar la definición, creo que hace falta vivirlo para terminar de entenderlo. Mejor aún, si entre todos los que participamos nos divertimos e intercambiamos experiencias y formas de hacer las cosas, creo que es la mejor forma de aprender Testing Exploratorio.
Esta dinámica ya la he puesto en práctica en Abstracta, Nahual, Anima, en clases en la Universidad, en varios clientes, en varios meetups, e incluso acá hay un video que quedó registrado de unas charlas en las que participé el año pasado en Córdoba.
Introducción al Testing Exploratorio
Para no repetir mucho sobre algo que ya muchos han escrito, te dejo una serie de links para que leas que a mí me parece que sirven para aprender al respecto:
Sobre la historia y evolución del Testing Exploratorio, te recomiendo leer este artículo de Javier Garzas, y la segunda parte acá. Básicamente cuenta cuándo se origina, y quiénes han contribuido en su definición, evolución, etc. Creo que es necesario leerlo y comprenderlo bien, y Javier logró resumirlo.
Acá están unas ppts que he utilizado para contar el concepto y motivación:
Sobre mob testing creo que también sería bueno leas este post en el blog de Javier, donde cuentan algo que también había leído en el blog de Lisa Crispin, sobre una dinámica que hizo Maaret Pyhäjärvi en el Agile 2015. Acá fue donde me inspiré para armar esta dinámica.
Testing Dojo: Dinámica de Testing Exploratorio
Hace un tiempo me propuse ayudar a difundir más el testing exploratorio tanto como esté a mi alcance. Creo que es una estrategia de testing muy útil y válida para muchos contextos y que está sub-utilizada, pero probablemente por falta de experiencia, por falta de animarse a probar, y creo que con leer la definición o los componentes de una sesión no es suficiente como para aprender cómo hacer testing exploratorio. De ahí la idea de hacer algo más que una exposición sobre el tema y hacer un taller en el que se ponga en la práctica el testing exploratorio entre todos los participantes.
Preparación
Se necesita una computadora conectada a Internet y a un proyector o pantalla, de modo que todos los asistentes puedan ver desde su lugar.
Por otra parte, se necesita un pizarrón para ir registrando los datos de la sesión. Entonces, al inicio, luego de explicar las ideas introductorias al testing exploratorio, se pueden anotar las distintas partes de un charter en el pizarrón, en una distribución tal como para que ahí ya lo usemos en la dinámica. O sea, quedaría así:
Los elementos de la sesión serían:
- Misión: el objetivo de la prueba, el “qué” vamos a probar. Se puede mencionar también algún aspecto o característica a la que prestarle atención. Por ejemplo: probar la compra de productos desde el celular. Según el momento del proyecto se tendrán misiones más generales o más específicas. Esto generalmente lo voy variando entre una vez y otra que hago la dinámica.
- Notas de prueba: el registro de lo que se hace, de lo que se cubre, una idea de más o menos lo que se probó. Esta sería la evidencia de prueba.
- Tester: generalmente pongo “todos”.
- Hora de inicio.
- Tiempo planificado para la sesión: esto depende del tiempo disponible, pero no debería ser menos de media hora para la dinámica.
- Bugs: para ir registrando los errores que se van encontrando en la sesión. Típicamente acá se deja nota de los IDs de los bugs registrados en la herramienta que se utiliza para esto.
- Problemas: si en la ejecución de la sesión se tuvo algún inconveniente que no permitió probar lo que teníamos en nuestra misión (si por ejemplo algún componente no estaba accesible, no contábamos con datos, etc.).
- Métricas: al finalizar la sesión calcularemos algunas métricas relacionadas a cómo nos fue, ya que en base a este análisis se puede llegar a sacar conclusiones de los siguientes pasos (repetir la sesión, dividir la sesión para el próximo ciclo de pruebas, etc.). Por ejemplo, las métricas podrían incluir:
- Porcentaje de tiempo dedicado a misión versus oportunidad (esto es, el tiempo que uno está concentrado en la misión inicial contra el tiempo que uno “se va por las ramas”).
- Porcentaje de tiempo dedicado a setup, testing y reporte de bugs.
Pasos para ejecutar la dinámica
El objetivo o misión que generalmente planteo, es el de probar la compra en una aplicación de eCommerce en media hora. En particular utilizo este sistema opensource que tenemos instalado en uno de nuestros servidores: opencart.abstracta.us, y en alguna otra ocasión utilicé algún sistema real (como el sitio de una página de ómnibus que da mucho juego, ya que ¡está llena de errores!).
Luego se estipula cómo se van a tomar las notas: en el pizarrón, completando lo explicado arriba, sobre el pizarrón con el “template” de la sesión. Es recomendable usar un color diferente para completar las cosas que el usado para ese template. Así entonces se irán anotando los riesgos y las preguntas identificadas, por otro lado las notas de prueba dejando un registro de todo lo que se va explorando, y por último, se registran los bugs que se vayan encontrando, solo los titulares, sin dejar demasiado registro al respecto porque sino el que vaya a tomar notas se vuelve loco. Alguna vez hice la prueba de ir completando un mindmap al mismo tiempo, pero queda muy cargado de cosas nuevas si la gente no está habituada a utilizar mindmaps.
Se solicitan dos voluntarios a pasar al frente, que son los únicos que no tienen que pensar:
- Uno para tomar notas en el pizarrón.
- Otro para ejecutar lo que la gente le indica. O sea, la gente dice qué probar, en formato “think aloud” y la persona en la computadora solo sigue las instrucciones sin aportar nada más.
Luego, para que no estén todos a la vez gritando a ver qué probar, se establece una dinámica de colaboración grupal, y acá es donde pueden entrar diversas variantes. Según el coding dojo, las dos variantes son estas:
- Codekata: una persona (o varias) exhibe la solución ya preparada al resto.
- Randori: se ataca el problema en parejas, uno es el piloto y otro es el copiloto, y se define un tiempo cada cuánto van rotando esas parejas, haciendo que participe todo el público.
A mí me gusta la siguiente dinámica:
- Llevo un objeto que pueda ser utilizado como para pasarlo fácilmente, por ejemplo, un bug de peluche.
- Solo puede hablar el que tiene el bug de peluche en la mano.
- Si alguien tiene una idea levanta la mano, y la persona que tiene el bug de peluche se lo pasa cuando considere.
- Si la idea que esa persona está pensando tiene sentido solo en ese momento, entonces levanta las dos manos. De todos modos la persona que está con el peluche decide si se lo pasa o no.
El que tiene el bug de peluche es el único que puede dar instrucciones al que está en la computadora, y el que está en el pizarrón va tomando notas de lo que va sucediendo (con poco nivel de detalle, como para que no se estrese realizándolo, pero que de todos modos quede un registro de qué se pudo probar).
Es fundamental guiar la dinámica, intervenir constantemente para aportar más ideas de pruebas, para hacer que todo se mueva ágilmente y con fluidez, para resaltar buenas prácticas de testing, para generar discusión, para preguntar “what if”, para motivar a los más callados, etc.
Luego de media hora de ejecución, toma de notas y bugs, y varias idas y vueltas, se detiene la ejecución y se analizan las métricas.
Al final de esto se hace una RETRO sobre cómo fue esa ejecución, qué cosas se hicieron mal o bien, cuáles son las cosas interesantes del testing exploratorio y cuáles son las que hay que tener cuidado, o cuáles son las limitaciones.
Aprendizajes al hacer la dinámica
Por lo general hay una serie de situaciones que se repiten cada vez que he hecho esta dinámica, y termino interviniendo y generando discusión con los participantes en estos puntos principalmente:
- Nos vamos por las ramas: Se definió una misión y la gente se va mucho por las ramas. Al tester le gusta el testing negativo, verificar la validación de campos, apuntar a los detalles. Esto está muy bien, pero si aún no sabemos si lo más importante funciona o no, no deberíamos concentrarnos en esos detalles. Los detalles deberíamos dejarlos para después de haber verificado lo más importante, como para apuntar a reducir riesgos.
- Revisar el reloj: La gente se cuelga a probar y se olvida del “plan” original. Si se había estipulado cierto time-slot para determinada prueba, por algo será. Lo ideal es intentar cumplirlo y analizar cómo seguir.
- Qué hacer cuando no sé algo, ya que esto es un juego y no tenemos a la mano a un product owner, o a un posible cliente o usuario como para sacarnos las dudas, acá lo que recalco es que está estipulado tomar nota de las dudas, ya que eso también es información que nos permite tomar decisiones. Las preguntas tienen un rol fundamental en el testing.
Luego, en la RETRO por lo general se llega siempre a este grupo de conclusiones:
- No es fácil aplicar testing exploratorio en todos los contextos ya que en ciertas ocasiones tenemos requisitos de presentar determinada documentación a los clientes, esperan verlo de forma más estructurada, saber exactamente qué es lo que estás probando, o qué es lo que vas a probar. Esto no resulta tan compatible con el testing exploratorio. De todos modos creo que se puede encontrar un balance.
- El testing exploratorio es ideal para cuando hay poco tiempo para probar y para corregir, o sea, necesito feedback lo más temprano posible. Si me pongo a desarrollar los casos de prueba para luego ejecutarlos, voy a demorar más que si comienzo directamente con testing exploratorio, ya que desde la primera hora comenzaremos con ejecución de pruebas y reporte de bugs.
- Es ideal para cuando queremos tener una primera aproximación al producto, o a las nuevas funcionalidades. La típica frase “probame esto fijándote que suceda tal y que no suceda cual, pero no le dediques más de 40 minutos”. Bueno, eso es testing exploratorio basado en sesiones. La diferencia es que de esta forma se enmarca un método claro y medianamente definido como para poder realizarlo (digo medianamente pero como algo positivo, porque cada uno lo puede adaptar a su gusto).
La última vez que hice esta dinámica fue con una aplicación con la que Bolton nos planteó un desafío en el curso RST cuando estuvo en Uruguay.
Para Cerrar
Para cerrar me gustaría citar una frase que hace poco me dijo un amigo:
Cuando un viaje está muy planificado pierde gracia, no es tan divertido.
Será por eso que me encanta viajar, y que me gusta más el testing exploratorio que los casos de prueba. ¿Vos qué opinás del Testing Exploratorio?
