Diagramas de influencia y Agile Testing

El 27 de febrero asistí a la Test Academy 2016 en Barcelona. Fue un evento con algunas sesiones interesantes y la que más me gustó fue Usando diagramas de influencia para entender el testing de Isabel Evans.

En este artículo utilizaré la técnica de los Diagramas de Influencia (ver pág. 16) para reflexionar sobre la transformación del rol del tester tradicional a ágil. Recomiendo revisar esta técnica por su utilidad para reflexionar conjuntamente con las personas de una organización sobre la complejidad de los procesos, roles, y crear entendimiento compartido que facilite la mejora sostenible.

Test Academy 2016 y Diagramas de Influencia

El 27 de febrero asistí a la Test Academy 2016 en Barcelona. Fue un evento con algunas sesiones interesantes y la que más me gustó fue Usando diagramas de influencia para entender el testing de Isabel Evans. En este artículo utilizaré la técnica de los Diagramas de Influencia (ver pág. 16) para reflexionar sobre la transformación del rol del tester tradicional a ágil. Recomiendo revisar esta técnica por su utilidad para reflexionar conjuntamente con las personas de una organización sobre la complejidad de los procesos, roles, y crear entendimiento compartido que facilite la mejora sostenible.

Diagrama desarrollado por Isabel Evans. Se dice que las disciplinas de la ingeniería de requisititos y de las pruebas (o testing) se están alineando con la agilidad porque:

1. Personas: antes las realizaban personas diferentes (analista y tester), y ahora tienden a compartirlas Product Owners y Developers (p.e. en Scrum).
2. Momentos: estas actividades se realizaban antes y después de la programación (respectivamente) y ahora se realizan durante el desarrollo (story test, tdd, bdd, sprint review, etc.).
3. Herramientas: se utilizaban herramientas específicas para gestionar requisitos y test cases, y ahora se tiende a utilizar herramientas comunes (p.e. Jira, Cucumber, etc.)

Un análisis detallado del diagrama anterior podria requerir mucho más espacio del que puedo dedicar en un artículo, pero haré un resumen de las consecuencias que me sugiere respecto a las actividades de calidad en el contexto de agilidad. Además recuperaré la pirámide de activdades del testing ágil de Mike Cohn, introducida en su libro Succeeding with Agile, y una pirámide de roles de testing, de elaboración propia, como el segundo elemento de reflexión.

Distribución “ideal” de los roles de testing

1) Tester desarrollador

Mike Cohn sugiere que las actividades de testing se automaticen y se centren el los roles desarrolladores (si juntamos el testing unitario y de integración, se habla de alrededor del 80% del esfuerzo de testing). Los motivos son:

1. Obliga a que los desarrolladores entiendan profundamente los requisitos funcionales y técnicos desde el principio. Tradicionalmente este conocimiento se fragmentaba entre analistas, programadores y testers, y además se realizaba en momentos diferentes y documentado de manera tradicional. Siendo un poco radical, afirmo que este enfoque es (era) una receta para el desastre, que requiere mucho retrabajo, cambios y solución de defectos (waste o desperdicio en Lean).
2. Los cambios y defectos encontrados por los desarrolladores son muy rápidos y seguros de solucionar, ya que tienen el conocimiento y las herramientas de desarrollo precisas para hacerlo en el momento.
3. Los defectos encontrados en la interfaz de usuario (UI) se han de reproducir y debugar, que resulta muy costoso. Más aún cuando los defectos se encuentran en producción.

Por ello, siguiendo las recomendaciones de reparto de testing, pienso que los desarrolladores con perfil de programación habrían de concentrar almenos un 50% o 60% del tiempo de testing.

2) Tester Integrado

El tester integrado sigue siendo un miembro del equipo de desarrollo, por lo tanto también se le debería llamar desarrollador. Su función, en el contexto de Scrum, debería ser la de liderar las actividades de testing no cubiertas por los programadores, pero siempre dentro del Sprint. Estas incluyen:

1. Realización del plan de pruebas que identifique las actividades y responsables del testing. Esto, por supuesto, no sugiere volver a los ciclos de vida de cascada ni de V-Model.
2. La automatización del testing funcional con actividades como el Behaviour Driven Development (BDD), implementadas con lenguajes de especificación de pruebas como Gherkin y herramientas como Selenium y Webdriver.
3. Preparación y realización del testing no funcional, como los test de carga, de seguridad, etc.

¿Puede seguir haciéndose un testing independiente? Mi opinión es que NO. En contextos donde haya una alta complejidad, por tener muchos equipos de desarrollo y productos grandes, puede ser interesante tener grupos especializados de testers dando soporte a los equipos de desarrollo, pero de nuevo, siempre integrados en el ciclo de sprints del resto de equipos.

3) Tester Especialista

Desde mi punto de vista, el rol de Tester Especialista, puede seguir existiendo pero abandona sus actividades tradicionales de planificación y realización de pruebas separadas del desarrollo. Su función debería estar orientada al desarrollo general de las actividades de aseguramiento de la calidad (QA) en la organización, coaching a los equipos, y coordinación con los responsables de arquitectura, seguridad, desarrollo, recursos humanos, DevOps, etc.