Te va a interesar!

6/recent/ticker-posts

Pienso (como tester), luego existo (como ingeniero de automation).




Ustedes saben que me encanta compartir un poco las vivencias que tengo como SDET en los diversos proyectos por los que paso. Este va a ser uno de esos posts. Preparen esos cafés, tés o mates y pónganse cómodos, porque vengo a decirles algo que a muchos quizás les choque! 

Un poco de contexto.


Cuando llego a un nuevo proyecto, un buen número de veces todo parece una maravilla. La automatización corre en segundos en sus pipelines de Jenkins, la gente baila tomada de la mano en verdes praderas ágiles de código deployado cada dos semanas en Producción y no hay nada que mejorar. Este fue el caso en la historia que les voy a contar, la cual pasó hace un tiempo.

En la misma entrevista me dijeron que tenían todo cocinado. Un framework sólido que brindaba todo el soporte que testers y devs necesitaban para automatizar las pruebas. Para mis adentros pensé "y para qué me están llamando si no tengo nada que mejorar?". Ohh iluso Yo del pasado! Ellos mismos sabían lo que estaba pensando, pero no lo querían admitir directamente. Cuando comencé mi primer día, luego de haber pedido todos los accesos pertinentes, entrenamientos y preguntar dónde está la máquina de café (el café de oficina en Nueva Zelanda es sorprendentemente bueno!) me puse a hacer lo que siempre hago al empezar un nuevo proyecto en un nuevo cliente: Ver sus procesos, investigar los repositorios asociados, el modelo de branching, el modelo de deploy a Producción y hablar con todos, desde los que diseñaron los frameworks a los que mantienen los pipelines en funcionamiento, a los que usan esas herramienta para llevar adelante su trabajo. En este caso, esos eran los Testers y Devs. 

No tardaron en aparecer los comentarios de descontento con la actual manera. Pero bueno, muchas veces esos comentarios están porque, seamos honestos, es difícil mantener a todo el mundo contento. Pero cuando empecé a hacer preguntas clave y obtuve las respuestas (que fui muy cuidadoso de doble chequear con otras personas), me sorprendí muchísimo. 

El actual repositorio donde para automatizar casos de prueba era una bestia enorme, con un tamaño colosal de clases sobre clases y más clases. El lenguaje era Java. Este repositorio tomaba como librería el framework propiamente dicho que se había creado para facilitar métodos que hiciesen todo por el tester/dev y no requiriesen mucho pensamiento. El mantenimiento se estaba haciendo difícil. Los muchos equipos que lo usaban pedían nuevos features para que sirva como herramienta en sus casos particulares. Aparecían errores que había que arreglar... nuevamente, estábamos ante un proyecto de automation que había crecido desmedidamente y ahora necesitaba trabajo en paralelo debido a su deuda técnica.

Ahora... la deuda técnica no le gusta a nadie, pero si a eso le sumamos un retorno de la inversión nula debido a que los casos de prueba automatizados que se creaban NO SE VOLVIAN A EJECUTAR (si, así como lo leés), el problema es peor de lo que pensaba. Todos sabemos que para que tenga sentido automatizar, a nivel negocio y a nivel sentido común, tiene que haber una reutilización de los assets que creamos. De ahí que el costo siempre sea alto debido al setup previo que se requiere y que vaya cayendo con el tiempo debido a que volvemos a usar tests que ya están creados y no deberían pedir más mantenimiento.

Bueno, acá la cosa era un gasto alto todo el tiempo sin tener a cambio mucho. Las regresiones no eran inexistentes, pero sí encontré luego de un análisis en los objetos que se volvían a tocar en Producción, que menos del 20% requerían que se ejecute. Menos del 20% de las historias que se entregaban al año pedían una regresión (y algún que otro fix que se metiese por un defecto que nadie vio). Del otro lado teníamos varios tableros de Jira con tareas de acá a la eternidad para actualizar el Framework, gente descontenta con el uso del mismo, la necesidad de capacitar a los equipos para usarlo y una duplicación de trabajo que encima era innecesaria en más del 80% de los casos.

Ahora sí, de lo que quería hablarles!


Esa fue una introducción larga! Pido disculpas. Pero con suerte siguen con el café o el té o el mate en la mano y no se durmieron! A lo que quería llegar con ésto es a algo que ya he mencionado en este blog varias veces: No pierdan la manera de pensar como Tester, incluso si tienen que pensar como desarrolladores para diseñar e implementar código que ayude a Testing.

Muchas veces, sobre todo cuando uno está aprendiendo o está detrás de ese jugoso ascenso, las personas tienden a sobrecomplicar las soluciones y no pensar realmente en qué necesitaban para testear algo. Hay casos en los que ni siquiera es viable automatizar. El caso del que les hablé arriba era uno de ellos. Era más fácil testear de forma manual cada vez que se trabajaba en una de esas historias que automatizar algo en el mediano/largo plazo.

Si yo hoy les dijera: "vamos a automatizar el testing de Mercado Libre", estoy seguro que muchos empezarían a pensar en herramientas. Que Selenium, que PyTest, que Cypress... en fin, hay mil opciones. Pero nadie va a pensar, primero y principal, cómo vamos a testear la aplicación? Qué requerimientos debería cumplir el testing para dar la información adecuada sobre el estado de la aplicación?

Por eso hoy quería decirles, sobre todo a los que se dediquen a automatizar: Frenen un poco y piensen cómo testar la aplicación más que cómo automatizarla. Retrocedan un poco y miren desde esa perspectiva de Tester y diseñen casos de prueba a conciencia. En los muchos equipos que trabajo y trabajé me encuentro conque los que automatizan se encuentran tan enfrascados en hacer que automation "ande", que pierden el foco del testing. No dedican el tiempo que deberían a pensar y diseñar casos. Eso hace falta más. Si se encuentran en una situación en la que el mantenimiento del framework de automation termina tomando más tiempo que el diseño de los casos de prueba, automation no está ayudando a testing, lo está complicando. Ahí es donde deberían replantearse cómo están haciendo las cosas.

Cómo ves en tu actual equipo o empresa está situación? Te tocó vivirla? Conocés a alguien que haya pasado o esté pasando por algo así actualmente? Te leo en los comentarios!

Publicar un comentario

1 Comentarios