Gracias por todo, no vuelvas más! El rol del Tester en Kanban

Kanban es uno de los métodos ágiles (1) más utilizados, junto con Scrum. Incluso, muchos equipos que dicen usar Scrum en realidad lo que hacen es Kanban o un híbrido entre ambos que se ha dado en llamar “Scrumban“.

Kanban está entre los modelos de proceso más livianos (menos prescriptivos) para trabajar en desarrollo de software. Esto quiere decir que sus exigencias son mínimas: apenas un tablero con columnas, que representan estados; tarjetas que representan tareas, y el principio básico de limitar el “work in progress“, es decir, la cantidad de tareas que pueden estar al mismo tiempo en una columna. Con esto solo se puede empezar a trabajar, resulta ideal para equipos que realizan mantenimiento de aplicaciones, aunque en realidad Kanban no se limita sólo al software, puede aplicarse a cualquier tipo de tarea, si bien cuando se trata de comenzar un nuevo desarrollo de cero, es aconsejable incorporar algunas prácticas de Scrum (convertirlo en Scrumban, como dijimos arriba).

El primer paso para implementar Kanban es conseguir un tablero, unas tarjetas (para representar tareas) y definir cuáles van a ser las columnas en el tablero, es decir, los posibles estados de nuestras tareas. Aquí es donde suele aparecer el primer problema, que es no definir al menos una columna para el Testing. Este error, que solemos atribuir a las metodologías ágiles (porque, es cierto, algunos de los libros clásicos de Scrum, XP o Kanban ni mencionan al Testing), es en realidad un viejo vicio de nuestra Industria, que cada vez que puede se inclina por hacer un Testing insuficiente, o directamente nada de Testing. A este viejo vicio, los métodos ágiles que omiten hablar de Testing le vinieron como anillo al dedo (2).

Sin embargo, la importancia del Testing está muy lejos de ser discutible. Según cálculos recientes, en Estados Unidos, los bugs de software que no se detectan durante el desarrollo y llegan al usuario final, producen anualmente pérdidas por casi 60 mil millones de dólares (la fuente, aquí). Esta simple estadística debería ser suficiente para ponernos de acuerdo en que es sumamente necesaria la tarea de Testing (cuya principal función es, justamente, evitar que los bugs lleguen al usuario final). El Testing es necesario sin importar la metodología o el modelo de proceso que se utilice y Kanban, por supuesto, no es la excepción.

En consecuencia, el primer paso, fundamental, para hacer Testing en Kanban (y para hacerlo bien), es definir al menos una columna (3) para las tareas de Testing. Esto viene de la mano con el concepto de “definition of done”, es decir, cuándo vamos a poder decir que una tarea está completa (“done”). Aquí, debemos luchar contra la natural tendencia de los Desarrolladores a considerar completa una tarea cuando terminaron de escribir el código. En realidad, una tarea no está completa hasta que está probada, hasta que superó el Testing. Por esto es una buena idea agregar a nuestro tablero una columna de Testing antes de la columna Done. Esto le da a todo el equipo una visión bien clara de lo que se debe lograr: cada tarea debe estar desarrollada y probada para considerarla completa.

Una vez que hemos logrado que el Testing sea parte del proceso, el mismo debería fluir naturalmente. No obstante, muchos equipos encuentran en el Testing un cuello de botella, donde las tareas se acumulan. La forma en que Kanban prevé lidiar con este problema es limitar el “work in progress”. Como dijimos antes, se debe definir un número máximo de tareas que pueden estar al mismo tiempo en una columna. Si se ha alcanzado ese número, no puede moverse una nueva tarea a la columna hasta haber sacado otra. Esto obliga a que el equipo tome un enfoque colaborativo y flexible, que en la práctica significa que todo el equipo se dedica a eliminar el cuello de botella (en el ejemplo del Testing, desarrolladores e implementadores se pondrían a ejecutar pruebas, hasta limpiar la columna de tareas). Esto, en el largo plazo, no es la solución ideal. Para evitar que Testing se convierta en un cuello de botella, es una buena idea utilizar la automatización.

La automatización no reemplaza al Tester (4). No es su objetivo, ni debería serlo. El principal objetivo de la automatización es aliviar al Tester de las tareas repetitivas, que tranquilamente pueden ser llevadas a cabo por un robot. La principal de estas tareas son las pruebas de regresión. Estas pruebas son repetitivas, monótonas, pero muy necesarias, es preciso ejecutarlas ante cada modificación del software. Es por eso que son candidatos ideales para automatizar, dejándole al Tester la labor más compleja de ejecutar pruebas exploratorias, donde se requiere el uso de su experiencia y su creatividad y donde, al menos por el momento, un robot no puede ayudar.

Hay otras prácticas que la aplicación de Kanban nos llevará a considerar, como la Integración Continua, o el uso de “andariveles”, que resultan muy útiles, pero que ya son parte de la práctica más avanzada de este método. Seguramente los abordaremos en un futuro post. Por el momento, nos quedamos con que la clave está en incorporar el Testing al proceso y, hecho esto, abordar una estrategia de automatización que nos ayude a evitar los cuellos de botella. Dejar al Testing afuera del modelo es un error que sólo conduce a grandes pérdidas y, en muchos casos, al fracaso del proyecto.

kanban_board
Ejemplo de un tablero Kanban

(1) deliberadamente evito el término “metodología”, lo cual Kanban no pretende ser y que no es apropiada para lo que es apenas un (pequeño) conjunto de prácticas. En la industria, sin embargo, es habitual referirse a estas prácticas como “metodologías ágiles” y hasta el momento no tengo conocimiento de que esto haya producido víctima alguna.

(2) Creo que el malentendido se origina en que los métodos ágiles proponen que se construya la calidad desde el momento cero (“build quality in”) y que sea responsabilidad de todo el equipo. Por ejemplo, un Desarrollador debería realizar pruebas unitarias de su código independientemente de otros tipos de pruebas que se realicen después. De ahí a eliminar el rol del Tester, hay un abismo (donde terminan cayendo muchos proyectos sin Testing…). Otra fuente de malos entendidos es que las prácticas ágiles no definen el rol del Tester (como no definen ningún rol en realidad), mientras que el rol del Desarrollador parece obvio, el del Tester no lo es tanto.

(3) Algunos equipos que llevan un tiempo usando Kanban definen más de una columna para el Testing. Por ejemplo, se podría tener una columna de Testing Funcional o Exploratorio, otra de Testing de Regresión y tantas columnas como tipos de pruebas necesitemos aplicar.

(4) Sobre este tema, te invito a leer nuestro post: ¿La automatización reemplaza al Tester?

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s