¿Realizas pruebas en áreas de alto riesgo, gran complejidad o que, en general, requieren una atención especial? En ese caso, el mob testing es, sin duda, un enfoque recomendable.
¿Qué son el mob testing y el mob programming?
En primer lugar, son dos caras de la misma moneda, aunque volveré sobre ello más adelante. Pero ¿en qué consisten exactamente? Espero que lo descubras a medida que avances en este artículo. Al igual que muchas otras tendencias e iniciativas recientes dentro del desarrollo de software, se trata de ser capaces de entregar al cliente el producto adecuado con el nivel de calidad correcto, mientras mejoramos continuamente nuestra forma de trabajar, comunicarnos y crear una comprensión compartida entre personas con diferentes experiencias, enfoques, funciones, etc.
El mob programming y el mob testing tienen su origen en la programación en pareja, por lo que conviene detenernos un momento para analizar en qué consiste realmente.
Definición de programación en pareja
La programación en pareja es una disciplina de Extreme Programming (XP) y una de las prácticas fundamentales en las que se basa XP. Según extremeprogramming.org[1], la programación en pareja puede describirse de la siguiente manera, en una interpretación libre por parte del autor:
Dos personas, un conductor —quien controla el ratón y el teclado— y un navegador —quien revisa el trabajo y aporta buenas ideas— se sientan juntas frente a una pantalla, con un único teclado y un solo ratón. Se turnan para controlar el teclado y el ratón. La ventaja es que dos personas pueden resolver los problemas más rápidamente que una sola. Trabajar juntas aumenta la concentración, ambas adquieren una mejor comprensión general y se genera una responsabilidad compartida. El resultado es un producto de mayor calidad.
Mob programming
El mob programming es la «programación en pareja llevada al siguiente nivel». En este caso, no participan únicamente dos personas, sino todo un «mob» reunido alrededor de una pantalla, un teclado y un ratón.
Pero ¿qué es exactamente un «mob»? Según el Cambridge Dictionary[2], la palabra «mob» puede referirse a tres cosas:
- una multitud numerosa y enfadada, especialmente una que podría volverse violenta fácilmente
- una organización de delincuentes
- un grupo de personas que son amigas o que tienen algún aspecto en común
«El mob programming, al igual que la programación en pareja, tiene como objetivo crear un producto de mayor calidad».
Dado que el mob programming, al igual que la programación en pareja, pretende crear un producto de mayor calidad y más correcto, probablemente las dos primeras definiciones no sean las más adecuadas. La tercera definición, «un grupo de personas que tienen algún aspecto en común», parece mucho más relevante. Pero ¿quiénes forman ese grupo y cómo surgió el mob programming?
La historia del mob programming
El mob programming fue «creado» por Woody Zuill [3] hace casi diez años, aunque quizá sería más exacto decir que fue «descubierto». Woody fue contratado por una empresa para ayudarla y uno de los aspectos en los que puso especial énfasis fue en que el equipo al que apoyaba debía desarrollarse y aprender cosas nuevas. Su idea era que, en lugar de que cada persona se sentara por su cuenta a leer un libro, escuchar pódcast, ver vídeos, etc., todo el equipo se reuniera para aprender en conjunto y aprender haciendo. Esto ofrecía varias ventajas: podían ayudarse mutuamente, el ambiente era más relajado que cuando existía la presión de entregar algo concreto en una fecha determinada y, en general, se generaba una mejor dinámica de grupo.
Comenzaron reuniéndose todos los viernes para aprender mediante distintos «experimentos de código». Al igual que en la programación en pareja, había un conductor y un navegador, pero en este caso también participaba un grupo de observadores. El navegador indicaba al conductor qué debía hacer, mientras que el resto del grupo seguía el proceso. Aproximadamente cada cinco minutos, rotaban las funciones para que todas las personas pasaran por los tres roles.
Lo hicieron cada viernes durante aproximadamente medio año y, durante ese periodo, mejoraron colectivamente su capacidad para escribir código más limpio, resolver problemas con mayor rapidez, encontrar soluciones más inteligentes, etc. El resultado fue un software significativamente mejor que el anterior.
Otro efecto fue que los miembros del equipo mejoraron considerablemente su capacidad para expresarse de forma clara e inequívoca, de modo que el conductor supiera exactamente qué código debía escribir para resolver el problema. Un día estaban a punto de comenzar un proyecto de mayor envergadura y se incorporaron más personas al equipo. El problema era que muchas de ellas no tenían del todo claro cómo debía desarrollarse el producto o cómo debía escribirse el código. Comenzaron con una reunión tradicional en la que debatieron los retos y distribuyeron las tareas.
Sin embargo, durante aquella reunión, en la que también probaron algunas ideas de programación, surgió de forma natural el patrón que habían desarrollado durante sus sesiones de aprendizaje: las personas adoptaron espontáneamente las funciones de conductor, navegador y observador. La diferencia era que los observadores ya no permanecían pasivos, sino que contribuían activamente a resolver los problemas y simplificar el código que se estaba desarrollando.
Así fue como se descubrió el mob programming: lo que había comenzado como un método semanal de aprendizaje evolucionó hasta convertirse en un proceso de equipo en el que todos se sentaban juntos para desarrollar el producto de forma colaborativa. En este momento también entraron las pruebas en escena, porque comenzaron a surgir preguntas sobre el producto que el equipo no podía responder: ¿debería funcionar de esta manera o de aquella? Faltaban determinadas personas en el equipo. Por ello, se incorporó un especialista del negocio que pudiera responder a esas preguntas.
«Se trata, en gran medida, de crear una comprensión compartida, analizar los retos desde el mayor número posible de perspectivas, resolver los problemas de la manera correcta y, en última instancia, conseguir el producto adecuado con el nivel de calidad correcto».
Partiendo de la idea de los tres amigos —desarrollador, tester y negocio—, tiene mucho sentido incluir las pruebas como parte del equipo. Se trata, en gran medida, de crear una comprensión compartida, analizar los retos desde el mayor número posible de perspectivas, resolver los problemas de la manera correcta y, en última instancia, conseguir el producto adecuado con el nivel de calidad correcto.
¿Tiene siempre sentido trabajar de esta manera? Probablemente no. Sin embargo, cuando existen incertidumbres, una gran complejidad, requisitos estrictos de cumplimiento normativo u otras áreas que requieren mucha atención, es sin duda un enfoque recomendable.
Al principio, la productividad disminuirá con toda seguridad, ya que todo el equipo tendrá que adaptarse a una nueva forma de trabajar. Además, durante la fase inicial probablemente surgirán numerosos retos relacionados con encontrar la sala adecuada, establecer el entorno físico apropiado, reunir a las personas correctas y conseguir que contribuyan positivamente al proceso. Muy pocos tienen tanta suerte como Woody Zuill, pero, a largo plazo, este enfoque sin duda generará valor para la calidad.
Mob testing
Aunque mob programming y mob testing deberían ser términos equivalentes, el mob testing también puede utilizarse como una disciplina independiente: una forma de testing exploratorio en un grupo más amplio. Al igual que en el mob programming, participa un grupo numeroso alrededor de una pantalla, un teclado y un ratón, pero en este caso el enfoque se centra exclusivamente en las pruebas. Cuando varias personas, de nuevo con diferentes perspectivas —los tres amigos—, se sientan juntas, suelen surgir nuevas ideas y enfoques que probablemente nunca se habrían planteado trabajando de forma individual.
Cómo empezar con el mob programming y el mob testing
Como ocurre con muchas otras cosas, conviene empezar poco a poco. Podrías comenzar como Woody y su equipo, utilizando este enfoque inicialmente como método de aprendizaje. Afortunadamente, existen muchos recursos excelentes para quienes quieran empezar a trabajar con mob programming o mob testing. Recomendamos especialmente consultar los siguientes sitios:
https://woodyzuill.com/ – la persona que inició todo este enfoque
https://maaretp.com/ – ha escrito numerosos artículos sobre el tema y es autora del libro Mob Programming Guidebook
https://www.lisihocke.com/ – practica mob programming e imparte ponencias y seminarios sobre este tema en conferencias
¿Necesitas ayuda?
Si necesitas ayuda para empezar a trabajar con mob testing o quieres obtener más información sobre el tema, no dudes en ponerte en contacto con nosotros en el +45 44 979 979 o por correo electrónico en info@testhuset.dk. Por supuesto, estaremos encantados de ayudarte.
Latest articles & Updates