Te va a interesar!

6/recent/ticker-posts

Por qué el más vago de los Test Engineers es el mejor.

Photo by David Clode on Unsplash
Ok, lo voy a admitir: Soy vago. Me da pereza hacer cualquier tarea que, considero, podría ser hecha de una mejor manera o sin tanto lío. Entonces...¿cómo hice una carrera de Test Engineer en la que terminé como especialista en el exterior en estos últimos más de 10 años? Hoy les voy a contar uno de mis secretos...

Volvemos a los besos secos en Automation...

Pusiste cara rara cuando leíste el encabezado, ¿no? ¡Apuesto que si! Y bueno, no estaba haciéndome el romántico ni haciendo alusión a Silvia Suller. Me refiero a las dos propuestas en el mundo del desarrollo de Software que hablan sobre cómo encarar la ingeniería: KISS (Keep It Simple Stupid) y DRY (Don't Repeat Yourself). En otro post les comenté sobre ellas así que no voy a volver sobre lo mismo acá, pueden ver qué son estas ideas en esa entrada

La relación, el tejido conectivo con lo que les vengo a hablar hoy, es sobre cómo ser extremadamente vago me ayudó a ser un mejor Test Engineer. Les cuento...cuando tengo que pensar una manera de hacer un trabajo de Automation, de alguna manera estoy alineándome con el Cliente. Yo no quiero trabajar demás y hacer cosas repetitivas y el Cliente ciertamente no quiere pagar horas que sean el resultado de repetición y tareas que podrían ser ahorradas.

Suelo tener un cartel en mi box para que, los que interactúan conmigo, entiendan mi postura. Este cartel dice: "Work smarter, not harder". Para los menos duchos en el idioma inglés esto es "trabajá de forma más inteligente, no más dura". Siendo Argentino como soy, es algo que llevo en la sangre también, solo que lo modifiqué un poco para no caer en el "lo atamos con alambre" que nos hace famosos. Les voy a contar cómo fue que empecé a trabajar de esta manera porque está relacionado con mis comienzos en Automation y siento que a más de uno le va a servir.

Una breve historia de mis primeros años aprendiendo a Automatizar.

Me habían encomendado hacer una prueba de concepto automatizando una herramienta web que había fracasado anteriormente cuando alguien había intentado usar QTP (en aquel momento se llamaba así, hoy la conocemos como UFT). Esto surgió porque dije que me aburría hacer el testing manual, no le encontraba sentido repetir todo. ¿Ven? Acá ya se empezaba a manifestar el Estilo del Vago. 
Tuve la suficiente suerte de que la prueba de concepto fuese un éxito porque me di mucha maña (y pasé muchas horas fuera del trabajo estudiando la herramienta que había elegido para automatizar, por aquel entonces Coded UI de Microsoft porque tenía la licencia en la empresa). Acá hago un stop para resaltar cómo no fui vago para aprender. Esto es algo importante de entender, porque muchos quizás, leyendo por arriba, estén diciendo "Pato es un vago que no hace nada!" pero lo cierto es que, para ser vago, hay que tener un conocimiento profundo para poder, justamente, hacer las cosas de forma eficiente. Vago para el trabajo, nunca para aprender, muchachines...

Cuestión que, como fue un éxito, me asignaron dos personas para empezar a trabajar. Una de ellas era un desarrollador hecho y derecho. El se puso a hacer magias increíbles con el código para automatizar y yo, un simple estudiante de Geología en ese momento, simplemente hacía mímica de lo que veía. Esto llevaba a un montón de cosas que eran al divino botón. Pero claro, yo no sabía programar, por lo que copiaba lo que sabía que funcionaba, lo cambiaba un poco para ver cómo reaccionaba a eso y en función a esto corregía y seguía. No era un proceso muy eficiente que digamos. Y este problema es algo que veo repetirse una y otra vez todo el tiempo con los testers que quieren aprender Automation: Se guían por copiar código y no por entenderlo. 

Aprender deliberadamente para ser un vago deliberado. 

En ese momento dije "bueno, no podemos seguir así. Voy a tener que entender todo desde cero para poder construir yo mis propias automatizaciones y hacerlo de la forma más eficiente." Y así fue, empecé por los conceptos de Programación Orientada a Objetos, a practicar construir distintas cosas por mi cuenta, a mirar el código que ya tenía y seguir su movimiento...así hasta que, luego de mucho tiempo de practicar intensa y deliberadamente todo lo que necesitaba, empecé a sentirme como pez en el agua con el código. En ese momento fui capaz de ver, con un simple vistazo, todos los errores, duplicaciones y malas decisiones que se toman a la hora de crear soluciones de Automation y corregirlas con lo que había aprendido. El usar cosas por el simple hecho de que ya estaba así pero nadie usa eso o no sirve, el duplicar código porque así se aprendió en su momento, el no aplicar la herencia, encapsulación...todo eso se empezó a mostrar evidente cuando miraba código ahora. Era como leer un idioma que antes no sabía y ahora entendía. Bueno, literalmente era eso. 

Y así fue como llegué a una conclusión: El mejor código es el que no hace falta escribir. Si, simplemente así. Si podemos hacer algo con muchas líneas menos de código, ESE debe ser nuestro objetivo. La simpleza hace a la elegancia en esta disciplina y menos es más

Conclusión. 

Lo que quiero que vos, que estás leyendo, te lleves de este post es que es importante, importantísimo aprender. Y que es más importante aún aprender deliberadamente. ¿Qué significa eso? Significa aprender porque sentís la pasión y curiosidad que motiva ese aprendizaje y no porque querés aprender lo más rápido posible para aspirar a un mejor sueldo o posición. Recuerden que ser vago para aprender es mala, malísima idea. Pero aprender de manera correcta permite ser un vago en el buen sentido en el futuro, ¡como yo! 

Y ustedes, ¿qué approach piensan que es el correcto? ¿Les resulta extraño leer a alguien fomentando la vagancia en la manera que hago? Me interesa leer sus comentarios!

Publicar un comentario

1 Comentarios