Te va a interesar!

6/recent/ticker-posts

Se terminó la mentira: El estado actual de Test Automation!

Vengo con una serie de posteos muy en la onda postapocalíptica! Qué me pasa? Acaso se debe a que veo malas prácticas que llevan al detrimento del concepto de Automation? Se deberá quizás a que es difícil mantener en las buenas prácticas a las empresas?

Bueno, si...puede ser un mix de todas esas cosas. Hoy les vengo a hablar del estado actual de Automation y por qué me parece que está en una decadencia particular. Prepárense un café, té o mate y vamos a hablar de esto!

Automation Testing...pero se olvidaron de la parte de Testing!

Hay algo de lo que les vengo hablando hace un tiempo ya en estos posts: El mindset de Tester vs el mindset de Developer en el mundo automation. Es como si los Test Engineers o los que se dedican a Automation (no son lo mismo!) fuesen parte de esta secta super hermética a la que es imposible entrar si sos un tester manual. 
A veces, esto se debe a que las personas no se encuentran seguras de sus conocimientos y temen exponer eso al explicar conceptos a la gente nueva. Otros, por simple miedo a que los que vienen les quiten trabajo. También los hay por orgullo. Muchos ven al Tester Manual como un inferior...algo completamente incorrecto y, seamos sinceros, infantil a esta altura del partido. 

Entonces tenemos a nuestros caros Test Engineers, que cobran más que el resto de los testers, con un mindset generalmente enfocado al desarrollo porque, claro que si, así están orientadas las búsquedas de los headhunters últimamente. Buscan desarrolladores que se sumen a testing, al famoso SDET (dios...vamos un par de párrafos y ya mencioné tres nombres distintos para los que automatizan los casos de prueba!). Estos entran, aplican sus conocimientos de desarrollo, pero con su poco background tester terminan haciendo lo que hace un dev. Intentar hacer que el código "pase" y listo. Que ande, de verde en Jenkins y listo, a otra cosa mariposa. Y eso sin mencionar que, de lo que un tester manual cubriría con testing exploratorio (al borde de la extinción), con Automation se cubre un % muy bajo de esto, lo que resulta en...defectos que se filtran a producción, incendios por todos lados, trabajos de urgencia y pérdida de confianza en automation.

La herramienta equivocada para el problema equivocado.

Y esto aplica mayormente a Automation de UI, no de WebServices, el cuál debería ser el que más tiempo ocupe de los ingenieros de test, como les comentaba en este post.

Llega el requerimiento, piden que automaticen las pruebas con Selenium para adelantarse y encontrar defectos. Pero...es que no entendieron? No ven la falla en este plan? La UI y su comportamiento probablemente cambien mil veces hasta estabilizarse. Automatizarla en esta etapa es suicida, una pérdida de tiempo y un camino sin retorno al fracaso. Pero sin embargo, es lo que se hace en muchos lados.

Si se fijan en las ofertas en el mercado, van a ver que una amplia mayoría pide Selenium. Esto en comparación con RESTful y SOAP. Por qué? Por qué piden ésto si, en teoría, REST y SOAP deberían ser el foco por amplia diferencia, dejando Selenium para unos pocos tests E2E de la aplicación una vez se estabilizó? Es porque el grueso asocia Automation con Selenium. El Manager que no sabe mucho del tema técnico, lo primero que piensa al decir "bueno, vamos a automatizar!" Es : "Con Selenium!". Y ahí ya entró en un tango que no va a poder bailar y lo va a llevar al desastre. 

A esto se suma la nula planificación de qué automatizar. Generalmente se cae en "necesitamos cantidad sobre calidad" y esto se debe a que no hay un análisis de impacto ante cambios en las aplicaciones. No hay quién se tome el trabajo de decir "esta es la conexión y dependencias entre los componentes, por lo que sabemos que esta release va a cambiar cosas en este componente, lo cual va a impactar estas dependencias, automaticemos ahí!". No...se toma el camino fácil a corto plazo. A veces ni siquiera termina siendo el fácil. Y ahí tienen, a los ingenieros de testing lidiando con código para que Selenium se comporte como un señorito inglés con una parte de la UI especialmente intrincada y que nadie va a tocar, o que no va a ser importada en absoluto, fallando en entregar valor con el trabajo hecho. 

Saben dónde están la GRAN mayoría de fallas que mis tests encuentran? En la configuración de ambientes. Y saben cómo me doy cuenta y evito correr en círculos leyendo toneladas de stacktrace y logs? Con muchísimos chequeos de integración para los componentes que hacen a mi aplicación bajo test. 

De esta manera encuentro errores en esta etapa, ahorrando tiempo a todo el equipo en investigación y adivinanzas, mientras mis pocos tests de regresión se corren solo si todo está bien configurado y entregando resultados que aportan valor.

Rant Off!

Tenía que hablarles de ésto porque, como saben, me gusta pensar que todos estamos para aprender, que tester manuales e ingenieros de test DEBEN trabajar juntos y que las cosas tenemos que hacerlas bien. No porque sea un maníaco del trabajo, justamente todo lo contrario: Soy perezoso. Y por eso, me gusta hacer las cosas una sola vez y perfecto. Así me ahorro rehacerlas en el futuro. 


Publicar un comentario

0 Comentarios