Algunas veces nos ha pasado de encontrarnos con clientes que han perdido la fe en la utilidad de los tests automatizados, no necesariamente por la calidad de las pruebas en sí, sino porque muchas veces no somos capaces de transmitir clara y continuamente el valor que las pruebas están aportando al proyecto. En este post Leticia Almeida y Matías Fornara (ambos de Abstracta) nos comparten algunas estrategias que hemos usado para intentar recuperar la confianza en las pruebas automatizadas.
¿Cuándo se pierde esa confianza?
Existe un gran desafío para el tester para integrarse a un grupo de trabajo nuevo y construir la confianza necesaria como para ser visto como un integrante más del equipo. Es fundamental que se realice un seguimiento para estar siempre alineados en cuanto a los objetivos del proyecto, ya que es muy importante poder darle el sentido correcto al trabajo que estamos haciendo en etapas tempranas del mismo.
Como todo desafío, no aprendemos a enfrentarlos solos, sino que aprendemos trabajando codo a codo con otros equipos y creciendo luego de cada experiencia. En algunas situaciones nos ha pasado, o hemos visto de cerca, que el equipo llega a cuestionarse la continuación de las pruebas automatizadas, o sea, ya habiendo invertido esfuerzo en preparar las pruebas, se evalúa si se desea seguir invirtiendo en mantenerlas o si tirarlas a la basura.
¿Pero cómo se llega a este punto? Creo que un factor común en todos estos proyectos, es que el trabajo de automatización se enfoca más en la creación de casos de pruebas que en analizar de manera frecuente el valor de este trabajo y alinearlo con las expectativas del equipo y lo que el negocio necesita en cada momento. Muchas veces, el requerimiento de las pruebas automatizadas es “quiero automatizar toda la interfaz de usuario”. Haciendo eso, a medida que pasen las semanas, el conjunto de casos de prueba aumentará, aumentando así el tiempo requerido para mantener esa automatización, analizar los resultados, etc. Esto es peor aún si se implementa todo tipo de casos de prueba, es decir, casos simples, casos complejos, casos difíciles de mantener…
Por ejemplo, en un proyecto en el que participamos, se llegó a tener un conjunto de más de 600 casos de prueba automatizados, sin tener claro quizá qué utilidad tenía cada uno, y con un costo de mantenimiento de pruebas tan alto, que muchas veces los tests daban falsos positivos que no se ajustaban por mucho tiempo.
Otra complejidad que se presenta con este tipo de enfoques es la dinámica que se genera. Se llega a ver la automatización como un proyecto aparte del desarrollo y no como una actividad integrada y alineada a los mismos objetivos. Puede pasar así que los primeros casos de prueba automatizados empiecen a quedar obsoletos, sin mantenimiento. Esto se dificulta muchas veces por el afán de automatizar todo, sin dar lugar a hacer los refactors que son necesarios para mantener una arquitectura de pruebas sana y estable.
¿Qué pasa ante todo esto? Pues se pierde la confianza en la automatización. En un caso así conviene hacer una pausa en la automatización para definir una estrategia para revertir la situación.
Lecciones Aprendidas
A partir de algunas experiencias donde hemos tenido que “luchar” para recuperar la confianza en los tests automáticos, es que nos parece interesante compartir las lecciones que aprendimos, viendo algunas estrategias que nos resultaron útiles.
Conocer los objetivos de las pruebas, priorizar para alcanzarlos
Es tal vez una de las lecciones más importantes: siempre apuntar a generar valor. Tenemos que tener siempre presente los objetivos del proyecto y el negocio en sí para poder ajustar los objetivos del proyecto de automatización. Una técnica que nos ha sido de gran ayuda para alinearnos en los objetivos es el uso de MindMaps. Esto nos ayuda a esquematizar los módulos y funcionalidades del sistema a probar y así, de una manera gráfica, ordenar prioridades y definir un plan.
Para esto es sumamente necesario ser uno más del equipo, y no hacer del proyecto de automatización algo que corre paralelo e independiente del desarrollo de la aplicación. Algo que nos ha resultado positivo ha sido involucrarnos en el marco de trabajo del equipo “Scrum” participando de reuniones diarias y demás eventos de esta metodología, buscando estar alineados día a día. Al participar de reuniones como estas, donde participa todo el equipo, se logra entender de las prioridades del proyecto así como las funcionalidades planificadas para cada Sprint. Como es de esperar, esta información es un input valioso para priorizar el trabajo de automatización.
Es importante distinguir el ROI de la automatización para los distintos módulos, de acuerdo a sus particularidades. Habrá casos donde por la tecnología usada, por dificultades de entorno, datos, ambiente, etc., será tan complejo lograr una automatización fiable, que se volverá preferible no automatizar. Por eso, no conviene comenzar con el objetivo de “automatizar todo”.
Visibilizar resultados y valor de las pruebas
Es importante dar visibilidad a los beneficios que las pruebas le dan al equipo. Esto se puede hacer al dar nuestro status en las dailys, que todos sepan en que estamos trabajando y en qué afecta a los demás o al producto, de esa manera también construimos la idea de que el ciclo de pruebas aporta algo real al producto, y es parte de la actividad de desarrollo. Incluso, lo ideal sería que la automatización no sea una tarea aparte, sino que sea parte del Definition of Done de las features a las que se las quiera automatizar. De esta forma, el equipo pondrá foco en que todo lo necesario para la automatización esté disponible a tiempo, de forma de terminar las tareas comprometidas para el Sprint.
Si bien el uso de herramientas como Jenkins facilitan la visibilidad de las pruebas, dando resultados constantes sobre el estado de las mismas, si no se controlan los falsos positivos enseguida se pierde la confianza, y la información que se reporta en las herramientas es desestimada. Ante este tipo de situaciones, una estrategia posible es dedicar esfuerzo para dejar ejecutando en Jenkins solo aquellos casos que se identifiquen como prioritarios y que ejecutan de manera consistente, fallando solo cuando efectivamente se presentan errores en el sistema. En este sentido me gustó un tweet de Katrina sobre una charla del Agile Testing Days 2017
If there’s a failing automated test and no one is fixing it, delete it. If people don’t care that it’s failing, they don’t care about what it’s testing. @PaulHolland_TWN #AgileTD
— Katrina Clokie (@katrina_tester) November 16, 2017
En un proyecto en concreto donde aplicamos esta estrategia, al inicio había aproximadamente 80 casos de pruebas ejecutándose en Jenkins de los cuales más de 50 casos fallaban, y luego del cambio logramos tener más de 50 casos ejecutando correctamente en Jenkins, recuperando así la confianza en el reporte de pruebas.
Lo importante aquí es que la automatización aporte al objetivo del testing: brindar información relevante a todos los interesados, sobre los posibles problemas que se puedan ocasionar, los riesgos, y en definitiva, sobre la calidad del sistema.
Generar instancias de intercambio de conocimiento
Es de mucha ayuda pedir la opinión de otros proyectos de automatización y generar un espacio de intercambio que amplíen la visión con la que estamos trabajando y enfocando el proyecto. Como resultado de este ejercicio siempre hemos obtenido resultados muy positivos, logrando entre varios equipos de trabajo y expertos en el tema obtener un conjunto de buenas prácticas y combinación de herramientas que mejoren la estabilidad de los casos de prueba.
Takeaways
En resumen, lo que queríamos que se queden de estas experiencias que les quisimos compartir acá:
- Saber para qué/quién están dirigidas las pruebas. Esto creo que es de suma importancia, sin esto el proyecto se convierte en el desarrollo de muchos casos de pruebas que pueden no tener ningún valor para el negocio.
- Priorización de módulos y funcionalidades. Saber por dónde empezar, planificar el trabajo acorde a las necesidades del negocio y ser ágiles en que si algo nuevo sale con más prioridad, por ejemplo una nueva funcionalidad, adaptarnos a eso.
- Generar un interés real de los desarrolladores (cliente) sobre los resultados y el valor que aportan las pruebas. Esto está vinculado con lo anterior, siempre apuntar a generar valor, y para esto es sumamente necesario ser uno más del equipo, y no hacer del proyecto de automatización un proyecto que corre paralelo e independientemente a desarrollo. Esto se podría lograr incluyendo en la planificación de las funcionalidades las tareas de automatización, o sea, planificar la tarea de automatizar una prueba como parte del Definition of Done de la feature.
- Consultar cómo se están manejando otros proyectos de automatización para aplicar un conjunto ya probado de buenas prácticas.
Y vos, ¿te has enfrentado a alguna situación similar? ¿Has tenido que recuperar la confianza de las pruebas automatizadas? ¿Qué estrategias utilizaste?
