Testers en un equipo ágil.

Este es un punto algo controversial y no poco discutido dentro de los círculos ágiles cuando se desean aplicar a un ambiente empresarial.

Comencemos por decir que el tester tradicionalmente es una figura antagonista para el programador; se ubica justo antes del paso a producción de una aplicación con el  propósito de asegurar la calidad del software para poder reducir los periodos de marcha blanca, tan costosos y difíciles.

Al otro lado del río, en los equipos ágiles, se promueve un desarrollo iterativo en el cual el usuario trabaja de manera muy cercana a  los programadores, junto a una agenda de publicaciones muy frecuentes para que el software tenga contacto con el mundo real lo antes posible.

Esto se puede entender porque el desarrollo en cascada nace desde la administración hacia los programadores, mientras que la agilidad nace desde los programadores hacia la administración. La administración tiende a ver al desarrollo de software como una linea de producción en donde se debe colocar un control de calidad, y cuando la metodología es en cascada, el control va al final. Los programadores por su parte ven a los testers como una resistencia para que el software pase a producción y muchas veces como un insulto a su inteligencia. Obviamente esto está exagerado y se presenta en muchos matices, pero es para ilustrar un punto: Es natural que en un lado los testers sean muy necesarios mientras en el otro lado se clasifiquen como desperdicio.

Pero analicemos un poco el rol real del tester. El trabajo de un tester es ponerse en el lugar de un usuario y utilizar las funcionalidades del software de tal manera que le hagan sentido al negocio y a los usuarios. Nuestra responsabilidad como programadores es entregar un software que tenga la calidad suficiente para que el tester y por lo tanto, los usuarios, puedan usarlo día a día. Se analiza desde percepción de rendimiento hasta usabilidad de las pantallas. Si el tester encuentra un bug en esta revisión es su deber rechazar el build y comunicar al equipo los detalles del error.

En la agilidad contamos con muchas herramientas de automatización en cuanto al aseguramiento de calidad: historias de usuario que definen requerimientos en lenguaje de negocio, pruebas unitarias guían el diseño interno de la aplicación y lo comprueban repetitivamente, pruebas de aceptación automatizadas basadas en las historias de usuario que garantizan cumplimiento, entre otras. Pero sobre todas estas herramientas están los principios sobre los cuales la agilidad se basa, especialmente la comunicación con el usuario, que al ser fluida y sin intermediarios garantiza un correcto entendimiento del negocio y los requerimientos.

Todo parece indicar que el rol del tester no tiene cabida en un mundo ágil, especialmente cuando la comunicación del usuario y el programador es tan fluida como para que el usuario siempre esté entregando feedback sobre la aplicación.

Pero hay un punto débil en este razonamiento. El disponer del usuario con tanta fluidez es imposible en la mayoría de los desarrollos empresariales. Los usuarios son personas productivas para la empresa cliente y por lo tanto el cliente es celoso del tiempo que invertimos con ellos. Pero no es posible desarrollar un software sin el usuario. Muchos de nosotros tenemos cicatrices con las que aprendimos esa verdad. Lo que necesitamos es un punto medio y ese punto medio es el tester.

El tester ágil es parte del equipo de desarrollo, muy cercano al product owner y a su vez cercano a los programadores. El tester participa de la escritura de historias de usuario y dirige la escritura de las pruebas de aceptación. En este esquema el trabajo del programador continúa siendo el entregar una historia desarrollada que cumpla las pruebas de aceptación. El trabajo del tester es probar la historia de usuario desde el punto de vista de un usuario, encontrar oportunidades de mejora, detectar problemas de usabilidad o inconsistencias con otras historias previas o futuras. (Un tester sigue sin poder hacer su trabajo si el equipo de desarrollo no entrega un sw de calidad suficiente para ser probado)

El tester tiene un acceso más frecuente a los usuarios que el equipo de desarrollo. Esto permite que una persona en el equipo esté enfocada en capturar las personalidades e idiosincrasias de los usuarios, pero sin eliminar completamente el acceso dirécto de los programadores a los usuarios. Podemos pensar en el tester como una especie de “cache” de los usuarios, una capa de abstracción.

Si el cliente permite acceso directo a los usuarios y a la vez permite que los usuarios tengan una aplicación en producción con cambios nuevos cada dos semanas, entonces tener un tester es efectivamente un desperdicio. Pero si cualquiera de estas facilidades (o las dos) es negada o reducida, entonces un tester permite tener un ciclo de feedback rápido y sano apesar de aquello.

Advertisement