Te va a interesar!

6/recent/ticker-posts

El Test Engineer y el Developer: Diferencias


Hace unas semanas que vengo con unos debates interesantes en los proyectos en los que trabajo: Es el Automation Engineer un Desarrollador? Es un Desarrollador el mejor candidato para ser un Automation Engineer? Dónde queda el Tester de toda la vida en este nuevo y feroz mundo lleno de código y dependencias?

Antes que nada, sepan que la tendencia hoy en día a la hora de buscar candidatos para un trabajo en Automation es que tenga los skills de un programador. Yo hace años hago entrevistas técnicas para gente que se postula para puestos de Test Engineer y esta tendencia va a ir en aumento más y más. Es por eso que quise empezar este espacio de aprendizaje con los conceptos fundamentales de la programación orientada a objetos y cómo se aplican éstos a Automation Testing (porque honestamente en pocos lugares relacionan estas dos cosas).

Voy a responder desde lo personal a las preguntas planteadas al principio:

Es el Automation Engineer un Desarrollador?

No, no es un desarrollador. Tiene los skills de uno? Si, comparte varios, desde luego. Pero hay algo fundamental que es diferente y muchos parecen NO entenderlo: El mindset.

A qué me refiero? Ambos tienen dos objetivos muy diferentes. El desarrollador busca crear algo que funcione según los requerimientos. El Automation Engineer simplemente busca automatizar las tareas repetitivas y tediosas del tester manual para que sean realizadas, sin asistencia, por un programa. Esta es una diferencia importantísima y les voy a explicar con ejemplos que me tocaron ver personalmente.

Developer wannabes

Hace un tiempo caí en un proyecto en el que llevaban un buen tiempo automatizando ya. Me llamaron porque, con el tiempo, lo que crearon se volvió una bestia imposible de mantener. El motivo? La sobrecomplejización del framework y la nula estandarización de qué hacer para cada caso. Algunos habían usado gradle, otros maven, algunos Groovy, otros simplemente java...

La complejización innecesaria del código había llevado a cosas impensables para cubrir un simple login a un portal. Los nuevos tenían problemas para que el proyecto ande debido a cómo se manejaban las dependencias con spring y la nula explicación del código, que se abstraía tanto que para dar con el comportamiento entero de una línea de código había que hacer una búsqueda del tesoro que ni les digo.

Los Automation Engineers se habían pasado al lado oscuro...habían perdido de vista el objetivo de su trabajo: Hacer más fácil el testing. Se habían enfocado tanto en hacer andar su código, que entre parche, atadura con alambre y demás habían terminado con otro proyecto con defectos, otro proyecto que, al fin y al cabo, necesitaba testing.

Conocen el concepto de Deuda Técnica? Bueno, acá la Deuda Técnica estaba en rojo y necesitaban ayuda!
Resumiendo un poco el trabajo hecho, mi saneamiento fue crear un framework de testing de acuerdo a las necesidades del proyecto, de fácil entendimiento para los nuevos automatizadores y robusto para que no sea un infierno mantenerlo. El criterio se dio gracias a entender la necesidad del equipo de testing y además contar con los skills de desarrollo necesario: Usaban Jenkins con pipelines hechas en Groovy, así que Gradle y Groovy fueron los elegidos para buildear, manejar dependencias y codear. Selenium Webdriver se sumó al mix, con una sólida página base que abstraía la lógica para acciones sencillas sobre las páginas. Rest Assured fue usado aparte en otro proyecto para manejar el testing de las APIs provistas por los amigos devs y listo, todos felices!

Con ésto no quiero decir que esté mal que un desarrollador automatice, ni que un tester no deba saber nada de programación para automatizar. Todo lo contrario: El desarrollador que quiera automatizar debe familiarizarse con los conceptos de testing, como así el tester debe familiarizarse con los conceptos de la programación.

Si son testers, en este espacio van a encontrar todo lo necesario para empezar a meterse en este mundo y trabajar de ésto. Si son developers, puede que encuentren más utilidad en este tipo de posteos teóricos más que los prácticos, aunque mi foco va a ser siempre usar los skills de desarrollador y relacionarlos de forma directa con su aplicación a los frameworks de Automation.

Conclusión

Eso es todo por hoy, quería compartir un poco mis pensamientos sobre algo que vengo debatiendo hace bastante y que me parece que sigue sin ser lo suficientemente hablado.

Estén bien, dejen sus comentarios con lo que quieran que se trate acá y no olviden suscribirse si encuentran útil el contenido! Todas las semanas voy a subir tutoriales, posts de cómo trabajar de ésto, mejores prácticas, dónde buscar y mucho, mucho más!

Publicar un comentario

0 Comentarios