¡Mob programming en testing! #Agile2015

Como bien comentó Javier en el post de este lunes (Agile 2015 Washington D.C. #Agile2015), pasamos la semana pasada en el Agile2015, en Washington D.C. Para mí ha sido una experiencia enorme, de la que he aprendido mucho y de la que también traigo muchas ideas nuevas.
Así que continuando con el resumen del Agile2015 que estamos haciendo, hoy os hablaré de una de mis charlas favoritas de toda la conferencia: “Explore with Intent – Exploratory Testing Self-Management” de Maaret Pyhajarvi.explore-with-intent-slide-1
He de recalcar, que aunque me he forzado a ir a charlas de temas muy distintos, muchas veces mis decisiones han oscilado entre ir al track de testing ágil o al de coaching (me encantan estos temas, que le voy a hacer), por lo que al ver testing exploratorio (Si no sabes qué es este enfoque recuerda el post ¿Qué es eso del testing exploratorio? ¿Y para qué me sirve?) en el título de la charla no me lo pensé dos veces. No obstante, el enfoque de Maaret me sorprendió, no me lo esperaba.
Tal y como se puede deducir del título, la ponencia estaba centrada en recalcar la importancia y los beneficios del buen testing exploratorio, y que el testing exploratorio no es probar por probar, ni descontrol ni ausencia de preparación ni documentación.
Este enfoque de testing tiene sus ventajas y se necesita una cierta experiencia y madurez que se va ganando con la práctica. Además una de las claves del éxito es saber gestionar bien las sesiones de testing exploratorio: centrarnos en un objetivo concreto, no divagar entre los muchos caminos a probar en la aplicación sin control, documentar y tomar las notas necesarias para que las sesiones sean útiles, saber tratar esos cambios de testeo/documento (o hacerlo al final de la sesión), etc.
Para intentar evitar algunas de las malas interpretaciones en torno al testing exploratorio, la ponente decidió cambiar ese nombre por “testing a fondo”. El objetivo de lo que iba a explicar en su charla es cómo cambiar nuestra mentalidad para probar a fondo una aplicación con el tiempo y recursos que tenemos, y gestionar mejor nuestro tiempo disponible.
Para ayudarnos en ese objetivo, Maaret expuso el esquema que siempre utiliza para planificar sus días de trabajo y que una vez cumplimentado sirve como parte de la documentación de la sesiones de testing exploratorio:
explore-with-intent
Donde cada cuadrado indica lo siguiente:
– Mission: Nuestro objetivo de la sesión. No hagamos cosas diferentes al objetivo de la sesión. Estoy es útil para focalizarnos.
– Charter: ¿Qué áreas de la aplicación queremos probar? En el caso de la aplicación que se tomó de ejemplo (una aplicación de creación de animaciones), podríamos tener como charters: Creación de una nueva animación, edición de una animación existente, flujos de animación, integración de la herramienta con photoshop…
– Other charter: Mismo concepto que lo anterior, pero aquí indicaremos ideas de charter que queremos tratar más adelante, que se nos han ido ocurriendo a medida que avanza la sesión. Lo que está en la sección Charter es lo que haremos en la sesión actual, Other charter lo dejaremos para después o para cuando terminemos de profundizar en lo indicado en Charter.
– Details: Aquí por ejemplo incluiríamos preguntas que nos surgen a la hora de interactuar con la aplicación durante la sesión, que luego consultaremos con el Product Owner o los desarrolladores, bugs encontrados (cómo reproducir dichos bugs), qué acciones se podrían automatizar, etc.
Lo que Maaret recomendaba es que montemos este diagrama a lo largo de la sesión (menos la parte de mission), sobre un cuaderno, una hoja de papel, o para facilitarnos los muchos cambios que este documento va a sufrir hasta su versión final, en forma de mapa mental. Herramientas como MindMup o XMind nos pueden servir para ello.
Hasta esa parte de la charla, genial, dentro de lo esperado, ideas para gestionar las sesiones de testing exploratorio. Ahora viene lo bueno.

Sesión de Mob exploratory testing!

Para poner en práctica lo explicado, Maaret guió a un grupo de voluntarios en una sesión de mob programming, con el objetivo de testear al máximo una aplicación que puso de ejemplo.
Ya escribimos hace un tiempo sobre esta técnica y sobre cómo la llevamos a cabo en 233, incluso para nuestras propias gestiones internas (#MobProgramming: caso de estudio y experiencias).
Para refrescarte un poco la memoria, Mob Programming consiste en que un grupo de personas se pone delante de un ordenador para trabajar en equipo con un objetivo concreto (programar, aprender, testear, etc.). Normalmente lo que se suele hacer es que lo que se ve en el ordenador está proyectado en una pantalla, y hay una persona que es el driver, que hace en el ordenador lo que los demás le dicen (que son los navigators). El rol de driver se va rotando cada cierto tiempo.
En este caso, la sesión de Mob programming consistía en un único navegador, una única persona que aunque debatía con los demás miembros del equipo, era la que finalmente le decía al driver lo que tenía que hacer en el ordenador (hacer click aquí, probar qué pasa cuando se hace esto, escribir aquello en el mindmap, etc.)
Maaret actuó de Product Owner de la aplicación, respondiendo a las preguntas que tuvieran los participantes y controlando el tiempo (cada 5 min el navegador se ponía en el rol del driver, y un nuevo navigator entraba en escena).
El resto de la gente que no salió voluntaria tenía que tomar notas sobre qué pegas encontraba en la actuación de los voluntarios, qué cambiaría, etc.
Realmente me hizo muchísima ilusión este workshop, porque encontramos bugs, colaboramos entre todos a pesar de no conocernos de nada, entendimos los conceptos…Incluso al final, hasta la gente del público debatía con los voluntarios.
Pero además, me alegra ver como además de que en 233 utilizamos esta técnica y la promovemos (incluso últimamente en sesiones de testing entre testers o entre testers y devs), hay gente que también la utiliza y le sirve. ¡Mob programming no es solo para programar! ¡Promueve la calidad en el equipo!

Terminando…

Aún así en la sesión quedó claro que todo no es perfecto, y que la primera vez que intentas realizar Mob Programming hay muchas cosas que mejorar. La cuestión es (como bien hicimos) hacer retrospectiva de la sesión, qué fue bien, qué no, qué tenemos que mejorar para la próxima sesión, etc.
Habilidades como cómo dirigir bien al driver, explicarnos bien, no perdernos en el debate, centrarnos en testear una parte de la aplicación cada vez…requieren su tiempo y práctica.
Por último quería recalcar algo que dijo Maaret sobre testing al final de la charla: aprender a testear es como aprender a conducir un coche. No intentes cambiar de marcha en la mitad de una rotonda si estás empezando a conducir: haz una cosa cada vez, cosas simples, practica en un sitio seguro…No intentes en cada sesión de testing exploratorio centrarte en mejorar todo, porque no lo conseguirás. Una cosa cada vez, con práctica se consigue todo.
PD: Me llevo la idea de los mapas mentales para las sesiones de testing exploratorio! 🙂

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “¡Mob programming en testing! #Agile2015”

Dejar un comentario

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