Scrum, un cambio de paradigma para el testing de software

Del trabajo en cascada a metodologías ágiles. ¿Qué diferencias hay entre Scrum y otros marcos de trabajo? ¿Por qué representa un cambio de paradigma para el testing de software y la calidad?

Tiempo atrás, publicamos un artículo en el cual indagamos si es posible contar con testers en Scrum. Tal como mencionamos entonces, cuando se trata de la creación de software de calidad, no solo “pueden” ser parte, sino que deberían serlo.

Luego, difundimos otro artículo en el que hicimos foco en la importancia de la agilidad, con una visión holística del testing, de la cual sin dudas Scrum forma parte troncal. Siguiendo esta línea de publicaciones, hoy voy a profundizar sobre la relevancia de utilizar Scrum en testing.

Trabajar con Scrum genera el necesario desafío de cambiar el paradigma del testing tradicional y especialmente el rol de tester. ¿De qué manera genera eso? Dado que Scrum adopta los principios que hay detrás del Agile Manifesto, es necesario generar software útil y entregarlo de manera frecuente.

Aquí, la única medida de progreso válida es “entregar software útil”. Para lograrlo, los testers y los demás integrantes técnicos deben trabajar pensando y coordinando juntos la “funcionalidad” (feature). Antes, se veía a la función del tester como alguien que debía probar lo que un desarrollador había hecho. Esto generaba un ciclo de trabajo en cascada.

Hoy el valor del tester es diferente: el tester es quién puede ayudar al Product Owner a escribir y pensar los criterios de aceptación. Es quién ayuda y promueve que el equipo de trabajo utilice nuevas prácticas de testing que no requieran únicamente esperar a probar lo que otro hizo. Se puede hacer pair-programming, implementar un pipeline de integración continua e incluso lograr una entrega continua del software. El cambio para generar alta colaboración es moverse en el paradigma DevOps.

Metodologías ágiles

Afortunadamente, hoy existen muchos marcos que ayudan a trabajar respetando los principios ágiles. Los más conocidos son: Scrum, eXtreme Programming, Lean software development y Kanban. Además, hay algunas versiones de estos marcos que ayudan a la adopción de métodos ágiles a nivel de toda la empresa. Scrum@scale, LeSS, Nexus, DAD, Enterprise Scrum, Enterprise Kanban y SAFe son de los más utilizados.

La diferencia principal radica en sus posibilidades de aplicación. Scrum es un marco totalmente agnóstico a la disciplina constructiva que se utilice.

Para ilustrar esto, puedo decir que, por ejemplo, mientras que eXtreme Programming fue creado específicamente para desarrollar software, se puede elegir recurrir a Scrum en diferentes industrias y áreas. Tanto es así que incluso ha sido vinculado a la enseñanza secundaria en países de Europa. Scrum está basado en eventos y actividades, y en todas ellas se ponen en práctica sus tres pilares: Inspección, Adaptación y Transparencia.

Todos los marcos colaboran con lograr la tan necesaria agilidad y resultan de gran utilidad, pero sin dudas, utilizar Scrum implica un gran diferencial. He estado utilizando Scrum desde hace 13 años, y he pasado por todos sus roles, pero también he utilizado Lean development, eXtremme Programming y Kanban, por lo cual hablo aquí en función de mi experiencia.

El marco que propone eXtremme Programming define el rol de tester, y también sus funciones. En cambio, Scrum no define ningún rol de especialidad técnica; todo lo agrupa en la definición del development team. Busca que ese equipo se autoorganice y tenga todas las habilidades necesarias para construir el producto. Esto permite que las personas que integran un equipo y usan Scrum puedan aprender de forma empírica cómo el equipo debe organizar y coordinar sus tareas, sin importar si una persona es tester, desarrollador, diseñador, etc.

Los equipos que realmente funcionan como equipos son aquellos cuyos integrantes tienen un fin común, y Scrum sprint a sprint tiene un objetivo común para todos llamado Sprint Goal. Además, promueve valores de trabajo en equipo como respeto, compromiso, apertura, coraje y foco, que ayudan a que los miembros del equipo aprendan a articular sus diferencias y trabajar siempre de modo colaborativo.

El evento llamado Sprint Retrospective le provee a los integrantes de un equipo Scrum la posibilidad de conocer la frecuencia en la cual van a parar de desarrollar para dedicarle un tiempo a reflexionar y sacar aprendizajes que deben ser aplicados en el siguiente sprint.

Tiempo atrás, cada disciplina técnica discutía por su lado cómo trabajar. Scrum promueve exactamente lo contrario: que se junten todas las partes, técnicas y no técnicas, para aprender cómo estamos trabajando y decidir juntos qué debemos cambiar para el siguiente Sprint.

¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y YouTube para ser parte de nuestra comunidad y enterarte de más novedades acerca metodologías ágiles!

¿Buscas ayuda experta en la transición hacia Agile? En Abstracta somos especialistas en Testing Ágil, crucial para lograr la excelencia en la experiencia de los usuarios y la calidad de software desde todas sus aristas.

Recuerda que las pruebas ágiles guían hacia una mejor calidad de tu software, y promueven la colaboración entre tus equipos y una cultura de feedback continuo.

Contáctanos y conversemos sobre cómo podemos ayudarte a potenciar tus soluciones digitales con buenas prácticas de Scrum en testing de software.