Te va a interesar!

6/recent/ticker-posts

Automation y Project Managers no técnicos


Hoy les vengo a hablar de un tema que estoy seguro que todo ingeniero de testing conoce: Trabajar bajo el mando de Managers no técnicos. A qué me refiero con "no técnicos"? Me refiero al perfil de Project Manager que se enfoca más en conseguir resultados sin estar tanto encima de la cuestión técnica. A ese manager que le decís: "Voy a automatizar toda la suite de regression con el buscaminas de Windows" y te asiente con una sonrisa diciendo "espero el status de avance este viernes!".

Para tener algo de contexto sobre lo que voy a hablar, les quiero contar cómo es la dinámica con un equipo de desarrolladores y su Manager. Al menos en mi experiencia, claro está...puede que exista el mismo problema en otros equipos!
Cuando se tiene un equipo de desarrollo, el Manager es, generalmente, un dev con muchísima experiencia capaz de detectar malas prácticas o acercamientos a un problema y prevenir eso. Cuenta con los años y el conocimiento para direccionar al equipo hacia la mejor solución posible dados los recursos que se tengan. Estamos hablando de un Manager Técnico, Hands On dirán algunos también.

En Testing, sucede algo un poco diferente, dado, creo yo, por cómo fue la evolución histórica en esta disciplina. Originalmente, si bien Automation lleva un largo tiempo entre nosotros, no era lo estándar en los proyectos. El Tester todavía no se había convertido en algo parecido a un dev. Eso cambió en los últimos años a pasos agigantados.

Hoy en día, la automatización de casos de prueba es algo casi obligatorio en cualquier proyecto Agile que conozcamos. La filosofía del Shift Left obligó a los testers a crear automatizaciones para el área de integración previo a cualquier regresión en el SDLC. Como sabrán, todo esto involucra mucha jerga técnica, mucho conocimiento y detalles que, si no se manejan, pueden llevar a la pérdida de tiempo (y dinero) en el testing de un proyecto. Lo que no evolucionó tanto aún en testing es el tema del liderazgo técnico. Cuando contamos con alguien con décadas de trayectoria, es probable que venga de una época en la que lo técnico no era primordial en el área de Testing. Y los que están metidos de lleno en lo técnico aún no cuentan con el tiempo o el interés de ser managers, ya que el cambiante panorama en Automation y el resto de las disciplinas técnicas siempre tienen algo excitante que aprender.

El problema actual, en mi opinión, es el de dar con estos perfiles de Testers con gran conocimiento técnico, que ocupen el lugar de líderes o managers de equipos de Test. Otro punto que pasaría a ser muy similar al mundo del desarrollo porque, afrontémoslo, Testing se parece cada vez más (aunque con sutiles y vitales diferencias).
Para los que deban lidiar con el liderazgo no técnico en sus equipos de Automation, es importante saber que este perfil de Manager o Líder no está interesado en qué protocolo o API usamos de manera magistral para realizar ese test. O en lo increíblemente complejo que fue realizar llamadas autenticadas con Mutual TLS para validar las respuestas del servidor. Tampoco van a poder ayudar si nos encontramos en Pampa y la vía al momento de tener que enfrentarnos a estos desafíos técnicos.

También va a ser importante bajar las expectativas a la realidad, ya que muchas veces nos vamos a encontrar con la ingenua idea de que automatizar todo. O también vamos a tener que levantar la mano cuando veamos que la dirección en la que se quiere llevar la automatización no es la correcta. Ese tipo de escenarios va a ser frecuente cuando estemos en equipos de este tipo y vamos a ser nosotros, como ingenieros de testing, los que tengamos que ajustar las velas para hacer las cosas bien.

Y ustedes qué opinan sobre este tema? Tienen a alguien que esté pasando por este tipo de situación en su trabajo como Tester? Compartan y difundan la palabra!

The Free Range Tester

Publicar un comentario

0 Comentarios