Pages Menu
Categories Menu

Posted by on Jun 17, 2016 in General | 2 comments

#MobTesting: uniendo #Mobprogramming y Testing Ágil

– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).

Como sabéis nos gusta aprender nuevas tecnologías, nuevas formas de trabajo, nuevas técnicas… además de seguir utilizando todo lo que haga que nuestro equipo tenga buena productividad, mejore y aprendamos unos de otros, transmitir nuestro conocimiento, y seguir forjando nuestra confianza y relación como equipo.

Es por ello que hoy hemos querido hablar de #MobTesting que consiste unificar Testing y #MobProgramming (te dejamos aquí un post sobre nuestras experiencias en Mob Programming), ya sabéis que venimos hablando de ambas cosas desde hace bastante tiempo y que además nos ayuda a conseguir lo que os comentábamos antes.

Por cierto, al igual que usamos el hashtag de #NoEstimates y #MobProgramming, os animamos a usar también el  hashtag #MobTesting para hablar de esta técnica en la red social Twitter =).

Conozcamos un poco más sobre #MobTesting….

¿Qué es exactamente #MobTesting?

Hace casi un año ya se hablaba por el blog de utilizar Mob Programming con Testing Exploratorio (debido a que gente del equipo de 233 estuvo presente en una de las conferencias sobre agilidad más importante, Agiles 2015, te dejamos aquí un resumen, os dejamos también una reflexión de Lisa Crispín que también asistió). Se hizo una breve introducción al #MobTesting a raiz de esta conferencia.

Las personas que han popularizado el término #MobTesting son Maaret Pyhäjärvi y Llewellyn Falco.

Maaret lo define como la técnica Mob Programming aplicado a cualquiera de las áreas del Testing. De hecho vale la misma definición de Mob Programming: “Todo el equipo centrado en mismo problema usando un ordenador, al mismo tiempo y en el mismo sitio”.

La mayoría de los aspectos prácticos también son lo mismos, una pantalla, un teclado, un proyector, todo el equipo, etc. Muchos de los beneficios de “Mob Programming” también los tenemos en #MobTesting.

Maaret lo utiliza sobre todo para Testing Exploratorio y para construir artefactos de automatización de pruebas. Considera interesante esta técnica porque tenemos que considerar el Testing como una tarea diaria que no se puede separar del desarrollo (te dejamos este post que habla de Testing y desarrollo).

Maaret distingue entre:

Por lo tanto las sesiones de Mob Testing pueden tener lugar en cualquier momento, es decir,  si lo utilizamos con BDD puede que hagamos sesiones de Mob Testing sin tener nada desarrollado.

A las sesiones de Mob Testing podemos invitar al Product Owner para conocer mejor sus necesidades (podemos hablar de Gherkin, te dejamos un post de buenas prácticas sobre Gherkin y escribir buenas feature), pero como veremos a continuación existen roles en el Mob Testing que podrán estar en contacto con el Product Owner para cualquier duda que pudiera surgir (te dejamos aquí una recopilación de post sobre el rol del Product Owner).

Los actores en #MobTesting

En primer lugar mirando responsabilidades compartidas. En #MobTesting podemos distinguir a los siguientes actores dentro del “Mob” (dejamos los términos en inglés porque la traducción no nos gustaba mucho):

  1. The Driver: como en el Mob Programming es la persona la cual va a estar en el ordenador, y se mueve a través de la aplicación.
  2. The Note Taker: Persona que toma nota de la sesión. Las pruebas y la toma de notas es muy difícil de hacer al mismo tiempo. Una de las ventajas es que alguien puede centrarse en la toma de notas a través de un mapa mental o a través de la grabación de preguntas, y otra persona en la parte de pruebas, aprovechando al máximo la sesión.
  3. El Orienteer: Es la persona que ayuda a mantener el rumbo de la sesión. A menudo es más fácil de conseguir el objetivo de la sesión seguido cuando se prueba lo que se necesita sin irse por las ramas, por lo que tener el beneficio de una persona para mantener a la gente concentrada puede ayudar y ser una ventaja.
  4. El Observer: Observa lo que está ocurriendo. A menudo una persona puede entrar “en ceguera temporal” cuando se está obcecado con algo. Simplemente, observando se puede ayudar a ver las dudas que el conductor pueda tener o pasar más tiempo resolviendolas, tal que incluso pueda pasar de largo.
  5. The Runner: En similitud con la industria de la televisión. Se podría utilizar a esta persona para obtener refrescos, piscolabis, o incluso mejor, si los que intervienen en la sesion de mob tiene preguntas para personas como p.e.  el Product Owner, preguntas como… “¿Es esto lo que se puede esperar?” Pueden correr a la persona y obtener un feedback rápido.
  6. The Local Expert: Es alguien que conoce el producto, sobre todo en lo que a detalles técnicos del producto se refiere. Esto ayuda si surge alguna pregunta, esta persona puede entrar y salir de la sesión o tal vez comunicárselo a la persona que ejerza de  “The Runner” para que él mismo lo haga.

Las personas que realizan estas funciones deben rotar cada 10-15 minutos permitiendo a todos pasar por todos los roles y dedicarnos a cada una de las actividades. También proporciona una buena oportunidad para practicar las habilidades de observación y toma de notas que luego se pueden aplicar cuando se trabaja de forma individual.

Diferencias en sesiones de #MobTesting

Cuando utilizamos Mob Programming para hacer Testing Exploratorio nos aconsejan utilizar mapas mentales para apoyar nuestra sesión de Mob Testing. Pero cada uno tiene una visión diferente en cuanto al uso de este mapa mental. Mareet transmite experiencias en talleres donde nos cuentan que se pueden hacer los mapas focalizándose en los errores o en la funcionalidad. Aún así Mareet lo utiliza como una herramienta secundaria. Sin embargo Llewellyn considera el mapa mental como un modelo que debemos ir haciendo desde el principio y tenerlo siempre presente.

En cuanto a las emociones de personas que están realizando la sesión también tienen distintas visiones. Al hacer sesiones de Mob Testing Llewellyn se focaliza en expresiones que llevan a emociones negativas, como por ejemplo la frustración con expresiones como “no me esperaba que…” así se puede activar la discusión sobre un posible error. Mareet cuando enseña cómo hacer Mob Testing habla de las emociones en general. En lo que coinciden ambos es que hay que estimular a las personas para que participen mediante las emociones.

Concluyendo…

Si alguna vez habéis participado en sesiones de #MobTesting nos gustaría que compartierais vuestra experiencia con nosotros. Nosotros, en 233 Grados de TI, hemos tenido alguna sesión de #MobTesting, en automatización de pruebas móviles con Calabash, de esta sesión no tenemos fotos que dejaros, puesto que estuvimos tan metidos en ello que se nos pasó.
No obstante nosotras hemos querido dejarte alguna foto de experiencia, no es exactamente #MobTesting, pero a modo de similitud de Pair Programming, podemos decir, que las fotos de nuestra experiencia y que os queremos dejar son de “Pair Testing”.

“Pair Testing” Exploratorio con Xamarín Test cloud

“Pair Testing” Exploratorio con Xamarín Test cloud

Te dejamos aquí el post sobre Xamarin Test Cloud y el vídeo demo a modo de recordatorio.

Pair Testing” Automatización con Calabash

Pair Testing” Automatización con Calabash

“Pair Testing” Automatización con Calabash

“Pair Testing” Automatización con Calabash

Te dejamos aquí un post sobre Calabash si quieres saber o recordar sobre este framework y un vídeo demo.

Quizá alguno nos preguntéis… ¿Chicas tiene sentido hacerlo para todas las actividades diarias de un equipo? Para terminar te respondemos a la pregunta con la siguiente sección de este post.

#MobAnything

De aquí, sacamos lo que vamos a llamar “MobAnything”. Hay ciertas actividades que tienen sentido no hacerse en grupos, o grupos grandes, al igual, otras actividades que sí. Además de “#MobProgramming” y “#MobTesting” otra actividad que sería interesante es “MobDrawing” ¡otra técnica más que probar e investigar!

Quizá algún día nos animemos a usarla también y te contemos nuestra experiencia con esta técnica. Aquí es donde todo el equipo se reúnen para elaborar un diseño de un nuevo producto.

Noemí Navarro Sánchez

Noemí Navarro Sánchez

Soy graduada en Ingeniería del Software y Scrum Master.

Actualmente formo parte de 233 Grados de TI - Comunidad y pertenezco al personal de investigación de la Universidad Rey Juan Carlos. Ayudando, con la difusión de buenas prácticas, a las organizaciones a mejorar en eficiencia, productividad, calidad en tiempo y con felicidad.

He formado parte de 233 Grados de TI - Empresa durante un año, donde me dediqué profesionalmente a mentoring ágil, calidad software, y donde participé en proyectos relacionados con la implantación de metodologías ágiles, Scrum, herramientas de gestión de proyectos y calidad del software para importantes organizaciones.

https://es.linkedin.com/in/nnsanchez92
Noemí Navarro Sánchez

2 Comments

  1. Estuve de observer en una acción formativa cercana a la entrega final. Fue una experiencia apasionante. Había más observers. Es el N eyes principle (cuatro ojos ven más que dos, seis más que cuatro…). Cada uno se centra en observar un aspecto. Cuando los observers no están muy preparados se tiende a grabar, o cuando están haciendo sus Ppropios estudios, sobre todo los relativos a PNL que suelen ser muy reveladores. El problema surge cuando falta preparación o información para evaluar la observaciones.

  2. Hola! qué buen post!
    Con algunas simplificaciones, lo he llevado muchas veces a la práctica para enseñar testing exploratorio, ya que en cursos anteriores me quedaba muy corto dar una clase “teórica” de testing exploratorio, cuando uno realmente aprende al hacerlo. Además, intentamos hacer algo del estilo “think aloud” para que todo lo que uno va pensando quede registrado, y que así se comparta cada intensión de prueba. Esto último ayuda a compartir “visiones destructivas”, como para mejorar las capacidades y las ideas de todo el equipo de testing.
    Saludos!

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This