The Free Range Tester

Soy un Test Engineer

The Free Range Tester

Más de una década usando diversas herramientas de Automation, best practices, frameworks y lenguajes de programación me llevaron a tomar el camino de la consultoría para formar profesionales de la más alta calidad, para un mercado creciente y en demanda constante.

  • thefreerangetester@gmail.com
  • www.patreon.com/thefreerangetester
Me

Contenido

En la comunidad de The Free Range Tester cubrimos un amplio abanico de técnicas y herramientas para darte flexibilidad en cualquier puesto de Automation Testing

Selenium Webdriver 99%
API Automation 90%
Katalon Studio 70%
Cucumber 90%
DevOps 90%

IDIOMA

Tu lenguaje, tus términos.

De Tester a Programador

Si nunca escribiste código o querés mejorar tus habilidades actuales, estás en el lugar correcto.

Costo accesible

Aprendé a automatizar con una suscripción mensual de solo U$D 2.

Flexible

Movete entre los distintos tiers según tu necesidad y conveniencia.

Entretenido

Didáctico e informal, en este espacio podés ser vos mismo y pertenecer a un grupo con intereses afines.

Una Comunidad

Charlas sobre código, automation, mejores prácticas, café...todo en un lugar.

0
Frameworks implementados
0
Tutoriales
0
Facebook Likes
0
Cafés tomados 2019
  • Katalon Studio: La solución definitiva de Automation Testing?


    Mucho se ha hablado ya sobre Katalon en infinidad de blogs, foros y dojos de testing en los últimos años. Qué digo! Si hasta yo mismo estoy enseñando en los Tutoriales a usar esta herramienta!

    Esta herramienta standalone de automatización cubre, a primera vista, todas las expectativas que uno pueda tener referentes a automation para UI, APIs, Mobile y pronto Desktop. Lleva ya unos cuantos años, aunque la popularidad empezó a dispararse hace unos 3 aproximadamente. Usa Selenium y Appium detrás de escenas para encargarse de la UI y mobile como mencioné antes pero acá está lo que lo diferencia: Es sumamente sencillo de usar para una persona que no sabe programar.

    Si les soy sincero, es una idea sencilla e inteligente que fue llevada a un nuevo nivel. Cuando uno se baja la aplicación de Katalon Studio y decide crear un proyecto, nos va a preguntar qué tipo de proyecto va a ser: Si para Browsers, APIs o un mix de ambos. De acuerdo a esto nos va a crear un proyecto ya armado con lo que yo llamaría un template con toda la estructura ya hecha, cosa de que uno se tenga que preocupar por empezar a crear sus tests directamente al evitarnos todo el trabajo de configurar el WebDriver, el runner, Cucumber, las dependencias...todo ya viene incluido de fábrica.

    A simple vista parece maravilloso, y en cierta manera lo es. Pero hay un par de problemas que lo hacen una opción no apta para el 100% de los proyectos. Veamos cuáles son esos puntos y tengan en cuenta esto si están considerando usar esta herramienta en sus equipos!

    El reporte se sube a sus servidores: Privacidad? Qué era eso?

    Este primer punto puede ser un deal breaker para muchos que trabajen con clientes que valoran la privacidad y confidencialidad sobre todas las cosas. Si queremos aprovechar al 100% los reportes bien lindos de la herramienta, estos se suben a Katalon Analytics, en su propia web, donde uno con un usuario propio puede entrar y ver todas las métricas y resultados. El sistema funciona de maravillas, se sube automáticamente y sin demoras, la interfaz es muy amigable y la información está ahí al alcance de la mano. 

    Pero con esa información hay también logs y cosas que, si trabajamos en entornos estrictos en los que no podemos subir estas cosas a la nube de los muchachos de Katalon, vamos a tener que desactivar esta función que, afortunadamente, viene desactivada por default. 

    También es cierto que vamos a poder generar nuestros propios reportes sin tener que acudir a Katalon Analytics, pero eso ya es algo que vamos a tener que hacer nosotros mismos y un poco pierde el sentido de tener todo en bandeja de plata, provisto por la aplicación. 

    Ideal para el 80% de las empresas...pero qué pasa con ese otro 20%? 

    Katalon funciona realmente bien y es muy robusto en lo que ofrece para automatizar. El problema empieza a aparecer cuando tenemos que lidiar con problemas atípicos en los que necesitamos customizar la solución de Automation. Lo que ofrece de fábrica no es suficiente y vamos a tener que arremangarnos y meter mano en el código. 

    Que necesitamos traer todos los resultados de una búsqueda e imprimirlos en un CSV de determinada manera...que necesitamos hacer un login mediante UI (sharepoint y sus mañas) para de ahí obtener el código que cambiamos por el Token para luego realizar llamadas con REST para validar OAuth...hay muchos casos de los más complejos que escapan a lo que ofrece Katalon de fábrica. Y de nuevo, vamos a terminar haciendo lo que hacemos con Java/Python/C# en nuestro IDE de toda la vida. Atentos si este caso es algo que saben va a pasar seguido en el proyecto en el que se desee implementar. 

    Incertidumbre sobre su futuro.

    Esta semana pasada anunciaron Katalon Studio Enterprise, actualmente en beta. Si, como adivinaste...van a cobrar una suscripción porque, claro que sí, vivimos en esta maravillosa era de "as a service". Por lo que lo que antes era un solo producto gratuito, ahora va a contar con un hermano mayor, una versión más "completa" por la que vamos a tener que pagar. Eso va a caer en la misma bolsa que otras herramientas que están en el mercado hace mucho, como Ranorex.

    Antes que esta versión más completa, el equipo detrás de la herramienta ya había implementado un Plugin Store en el que, entre cosas gratis, también hay muchos plugins pagos. Por lo que es seguro afirmar que la tendencia a buscar cómo hacer alguna ganancia de este proyecto, sobre todo con la popularidad creciente de la que goza, es una apuesta bastante segura. Y está perfecto, de alguna manera tiene que subsistir...pero hay que ver cómo manejan el asunto. 

    Tampoco sabemos qué tanto soporte irá a tener la versión gratuita de Katalon Studio, por lo que esta incertidumbre es algo a tener en cuenta cuando consideramos una herramienta en la que invertir tiempo y esfuerzo en implementar en nuestro equipo/empresa. 

    Conclusión: No todo lo que brilla es oro.

    No me malinterpreten: Adoro Katalon. Soy un fiel seguidor del proyecto desde hace mucho. He intercambiado mails con el equipo, sugerido cosas, testeado features y, como les dije, estoy enseñando a usarlo en los tutoriales del Patreon. Solo que considero que no es una Panacea de Automation y que debe ser elegido ciegamente por sobre otras opciones ni mucho menos por encima de aprender directamente cómo automatizar con código, desde cero

    Muchos casos en los que he trabajado y trabajo se benefician o beneficiarían de usar Katalon debido a lo potente y sencillo de usar que es. Pero también se que puede sonar tentador implementar una herramienta que "no requiere saber" para así ahorrar unos billetes. Creanme...esa nunca fue la solución, a largo plazo, para nadie! 

    Los espero en próximos posteos y, como siempre, no olviden pasar a mirar los tutoriales!
  • Se viene el problema del crunching?

    Hace unos meses veía en las noticias del mundo del desarrollo de videojuegos (da la casualidad que tengo como hobby crear fichines y me gusta mantenerme actualizado) una problemática que se destapó como una olla a presión: El crunch.

    Esto que se conoce como "crunch" significa, simplificando un poco, la necesidad de trabajar muy por encima de las horas estipuladas para llegar a terminar actualizaciones que tienen que ser entregadas cada vez más rápido. Es algo que pasa especialmente con empresas AAA y recibieron muchas denuncias por parte de sus desarrolladores por tener jornadas de hasta 16 horas para llegar con la fecha de entrega de un parche por ejemplo.

    Estos períodos de tiempo, que muchas veces son para un hotfix por errores que, a todo ésto, vinieron causa de tener que entregar las cosas más rápido de lo que se pudieron probar como dios manda, pueden ser una semana, varias semanas y en los peores casos meses.

    DevOps: Amigo o enemigo?

    Todo esto se ve potenciado por las prácticas de DevOps, donde se acelera todo el proceso con integración continua, delivery continuo y todo el tiempo se están entregando pequeñas actualizaciones al usuario final que, si hay algo que no le gusta, es esperar para que solucionen cualquier error, pequeño o grande por igual.
    Ahora DevOps, bien implementado, te deja un pipeline y culturas de comunicación espectaculares que logran que de A a Z todo fluya con interacción humana mínima. Pero he aquí el problema amiguitos: Lo que DevOps se encarga de agilizar mediante automatizaciones, cambios en la cultura de trabajo y herramientas, es el trabajo que lleva horas humanas detrás. El desarrollo del software y los errores y sus correcciones son algo que necesita de la mano desarrolladora detrás. Todo esto me llevó a un perturbador interrogante...

    Puede ocurrir el crunch fuera de la industria de los videojuegos?

    A ver, primero y principal, no veo motivos para decir que el software no relacionado a los videojuegos está exento de ser una potencial víctima de estas prácticas. La cultura actual es la de entregar los updates, correcciones y mejoras con la mayor velocidad posible al usuario. Una diferencia quizás que sí puedo señalar, habiendo trabajado como Tester tanto en videojuegos como software no gamer, es que en el SDLC de juegos el Testing se suele tener en menor estima que en los segundos. 

    Esto lleva a que más errores pasen a Producción y que existan mayores corridas para responder a los furiosos gamers que usan las aplicaciones. El resultado es que estás corriendo para apagar incendios todo el tiempo, perdiendo la confianza de los usuarios y al mismo tiempo agotando peligrosamente a tus desarrolladores. 

    En empresas gigantes como Rockstar con el lanzamiento de su último juego Red Dead Redemption 2 tuvieron que salir al cruce de empleados denunciando unas políticas abusivas para llegar a entregar el producto que ellos querían en el tiempo que necesitaban. 

    Existe una solución actualmente al Crunch?

    Ni. Todo esto generó una charla muy interesante sobre la creación de gremios, sindicatos, que aboguen por la salud mental de los desarrolladores y se denuncien estas prácticas para que no ocurran. Pero no se qué tan efectivo puede ser eso en la práctica. Siempre va a estar el que necesite el trabajo más que el que denunció y esté dispuesto a estirar sus horas de trabajo en favor de la empresa para asegurarse su puesto. 

    En la industria indie la cosa pasa por la presión que uno se pone personalmente, siendo más una decisión de frenar un poco y entregar los updates a ritmos sanos, pidiendo la comprensión de los usuarios. 
    En el mundo que nos movemos nosotros en Testing de Software, no creo que sea un problema para nosotros testers. Los que sufren ésto son los desarrolladores más que nada. Si hay automatizaciones en su lugar, todo el trabajo humano puede ser validado por estos scripts en el pipeline, dando lugar al deploy en caso de tener todo en orden. 

    Lo que me lleva a una conclusión, nuevamente, perturbadora: El cuello de botella empieza a ser el ser humano en el mundo del software. Pensemos sobre lo que les decía al principio. Jenkins, Automation, CI y CD...DevOps, todo eso lleva a automatizar trabajo humano durante todo el pipeline del software. Desde que se escribe el código y se manda a la herramienta de SCM de turno hasta que a uno como usuario le cae el update. 

    Pero...qué pasa cuando toda esa rapidez tiene al usuario clamando por errores o cambios en la experiencia y se vuelve al papel en blanco y el desarrollador tiene que hacer algo al respecto? Ahí es donde se encuentra el problema en la actualidad y, déjenme decirles...creo que es una problemática muy interesante que se nos viene en el horizonte y va a demandar cambios radicales en cómo se desarrolla el software.  

  • Reusabilidad vs simpleza en el código: Existe un balance?

    Hacía tiempo que no escribía por estos pagos, no? Estuve a mil con los clientes, los tutoriales del Patreon y otros proyectos personales con los que estoy trabajando. Estoy enseñando también a un grupo de 50 (!!!!!) personas de acá lo mismo que están viendo ustedes en el Patreon! Solo que en vivo en una oficina.

    Entre todo este caos de proyectos, enseñanzas y el fin de año que se está acercando a un ritmo vertiginoso, tuve un par de charlas que me anoté y fueron a parar a una tarjeta de mi Trello personal para escribir acá. Y hoy traigo una especial que pasó hace relativamente poco. Preparen un té, café o mate y vamos con el post de hoy!

    KISS vs DRY.

    No, no me volví loco. Así se llaman dos de las corrientes filosóficocuánticas de la programación. KISS es para Keep It Simple Stupid y DRY va para Don't Repeat Yourself. A grandes rasgos, lo que dice KISS es que nunca la simpleza tiene que ocupar un segundo lugar frente a la reusabilidad, mientras que DRY dice justamente lo contrario. No escatimes reusabilidad, aun si hace falta hacer las cosas un poco más complejas. 

    Cuando uno está programando, es generalmente una buena práctica hacer que las funciones sean reutilizables, fomentando el concepto de Don't Repeat Yourself. Esto es por un tema de mantenimiento y para evitar tener que reescribir algo que, a todas luces, vamos a necesitar usar de nuevo en otros lugares. 

    Al mismo tiempo, es fácil meterse en el baile de empezar a hacer todo tan abstracto y "dinámico", que para una simple acción hace falta seguir un rulo de código interminable que hace que la reusabilidad sea más un parto que una bendición.

    Dos cosas me pasaron en los últimos meses con este tema e hicieron que se me prenda la llama latina en el equipo, haciendo que ponga los puntos sobre las íes para corregir algunas cosas.

    El Mundo a veces no es necesario...

    El primer caso fue con el uso de inyección de dependencias, para mantener la instancia del WebDriver y otras cosillas, en un proyecto con una sola clase para las definiciones de Steps y que solamente validaba una acción muy sencilla que no requería más. 

    El uso del objeto World para ese caso fue arbitrario, heredado de otra persona que, supongo, había tenido la necesidad de crear ese tipo de proyecto al tener que lidiar con algo más grande. En este caso, no solo era innecesario sino que traía una complejidad innecesaria que hizo preguntarse a varios de los que usaron ese framework "qué está pasando acá?" Sin mencionar que hubo entuertos para hacerlo más amigable a los que no estaban familiarizados con el concepto y muchos dolores de cabeza.

    En este caso, DRY>KISS. Se intentó. intencional o accidentalmente, dotar de una reusabilidad no requerida por el proyecto y eso aumentó exponencialmente la complejidad, trayendo una retahíla de Pull Requests del averno que me dieron ganas de tirarme de palomita al frío mar del Pacífico. 

    Envolviendo a Rest Assured para que sea más difícil de entender.

    Esta segunda situación es un poco más compleja. Resulta que había que hacer un trabajo muy grande, con un framework que usa Rest Assured. El framework es sencillo de usar y super versátil, de hecho es el que hicimos en los tutoriales del Patreon. Entró una persona nueva, con un mindset más de desarrollador que de Tester y empezó con los "y qué tal si agrego ésto..." 


    De repente, los pasos que eran hacer requests con lo que Rest Assured te da, se habían convertido en una ensalada de otras 4 clases, una para cada tipo de Request usada en el proyecto, metidas bajo capas y capas de complejidad innecesaria. Adivinen quién heredó el cataclismo para arreglarlo? Si...

    Lo que se había intentado hacer, y lo entiendo y hasta cierto punto lo veo bien, es lograr que los Features de Cucumber se comportasen similar a lo que sería el Framework Karate para trabajar con APIs. Hacer todo dinámico y, desde Gherkin mismo, decir qué cosas queríamos meter en el body del request y demás, sin tocar código detrás de escenas. 

    El problema fue cuando se entusiasmaron tanto con ir agregando cosas, que después hubo que agregar cosas para arreglar las cosas generadas por esas cosas y todo terminó en un ovillo de lana enredado que fue difícil encarrilar. 

    Conclusión. 

    Como le dije a la persona que terminó en ese lio: Si llegas a un punto en el que ves que tenés que empezar a arreglar tu propio código demasiado seguido para hacer lo que querés hacer, y eso encima te frena en entregar el trabajo que tenés que entregar...ahí creo que tenés un buen indicativo de que no deberías seguir por ese camino. 

    Mantener las cosas ordenadas y simples debería ser una prioridad porque, quieran o no, a veces uno puede pecar de desarrollador y terminar por un camino de complejidad innecesaria que no solo no resuelve ningún problema real, sino que termina añadiendo futuros problemas, deuda técnica y desconfianza general hacia el código. 

    Ustedes qué opinan? Me interesa saber la opinión y si son desarrolladores o testers!



  • El Test Engineer y el Automation Tester: Diferencias y similitudes.

    Buenas y bienvenidos a un nuevo post! Hace un tiempo ya les hablé de las diferencias entre el Test Engineer y el Developer. Hoy se me ocurrió poner enfrentados al Test Engineer y el Automation Tester, ya que veo que en el ambiente hay mucha confusión sobre qué hace uno y qué hace el otro, generalmente concluyendo en que ambos son lo mismo.

    Esto empecé a verlo mucho más una vez empecé a trabajar en el exterior, donde el término Test Engineer es más usado que en Latinoamérica quizás. Agarren esa taza de café, preparen los anteojos y vamos a hablar sobre esto!

    Automation Testing: Mirá mamá, sin manos!

    Cuando hablamos de Automation Testing y el Tester que se dedica a Automation, generalmente lo que pensamos es en este nerd escribiendo código para que pasen cosas en la pantalla sin que nadie esté manejando el mouse o el teclado. Si bien es una simplificación un tanto grosera, sobre todo considerando que existe un mundo llamado API Testing que debería ser el foco de las automatizaciones, es algo bastante acertado. 

    El rol del Automation Tester es justamente ese: Cubrir los tests manuales existentes con automatizaciones que ejecutan esas mismas acciones pero sin la intervención humana. En este rubro generalmente están los que comienzan su viaje en Automation, developers juniors que pasaron por algún motivo a Testing y Testers que quieren dar el próximo paso. 

    Las actividades se centran en automatizar, mayormente, UI con herramientas como Selenium, Ranorex, Katalon y otros. También me gustaría incluir a los que escriben tests de integración, API, con Rest Assured y otras herramientas del estilo. Como se darán cuenta, la actividad de este Automation Tester no dista mucho de la del Tester en cuestión, solo que lo hace valiéndose de programas que lo ayudan. 

    Test Engineer: Necesitamos construir una bicicleta para ayudar a Testing? Déjenmelo a mi!

    El Test Engineer es alguien que ya posee conocimientos de programación más profundos. En general es el que se encuentra en un equipo centralizado (o a veces es un equipo de una persona), encargado de ayudar a los Automation Testers cuando se traban con algo y no lo pueden resolver. 

    También van a ser los encargados de escribir programas que ayuden a Testing y, muchas veces, a Automation Testing. Por citar unos ejemplos en los que trabajé en el pasado: 
    • Creación de Test Harnesses para ser usados por los Automation Testers para crear y ejecutar sus pruebas.
    • Creación de Pipelines coherentes que creen los artefactos de output de testing necesarios para reportar. 
    • Creación de los artefactos necesarios y su mantenimiento, como clases que lidien con parte de la funcionalidad interna de la aplicación bajo test.
    • Desarrollo en general de assets para ser usados en testing como Jobs de Jenkins que completen páginas de Confluence con información de lo que se tiene, creación de JARs con los tests para desacoplar Jenkins de Bitbucket, librerías compartidas para ser usadas en los pipelines de Jenkins, etc.

    Como ven, el Test Engineer se encuentra menos involucrado en las primeras líneas de Testing puro y duro, estando detrás y dando soporte a Testing Manual y Automation Testing con los assets que crea. Generalmente este puesto es el que llenan los que más experiencias tienen, muchas veces desarrolladores puros y duros que no saben mucho de Testing, en raras ocasiones Testers que lograron mucha experiencia en desarrollo (mi caso), y trabaja codo a codo como un pivote de varios engranajes del SDLC. 

    Conclusión...

    Si bien suena tentador considerar que son lo mismo, me encontré muchas veces haciendo entrevistas a gente que se postulaba como Test Engineer y nunca había creado un asset para ayudar a Testing digamos. Solo habían hecho algo de Selenium basados en un Framework creado por otra persona. Y es ahí donde la dura realidad pega y siento que es necesario hacer una diferencia para que podamos enfocar nuestra aprendizaje en la rama que más nos guste. 
  • El desafío de implementar DevOps cuando trabajas con distintos vendors.

    Ohh si amigos. Levantarse temprano, leer una frase motivacional sobre una foto de un cachorrito, escuchar a los pájaros cantar e intentar implementar DevOps en un cliente con una fauna variopinta de vendors que trabajan en los mismos proyectos.

    Es la imagen misma de la inocencia, no creen? Sobre todo porque creemos que todos vamos a estar remando para el mismo lado...pero a veces, queridos lectores, no es así. Preparen un café y pónganse cómodos en esta fría mañana de Invierno, porque les voy a contar una historia sobre cómo una gran idea no pudo ser concretada debido a ésto y la conclusión a la que llegué.

    La(s) idea(s): Mejorar el SDLC introduciendo procesos DevOpsianos para mejorar la toma de decisiones.

    Se que puede sonar un poco técnico, pero la explicación es en realidad sencilla. Noté que en la empresa se usaba una herramienta (digo "noté" porque fui yo el que configuró la herramienta) en sus equipos de desarrollo. La herramienta en cuestión es Sonarqube, la cual sirve para, a grandes rasgos, hacer un análisis estático en el código y levanta advertencias, vulnerabilidades, bugs, falta de Unit Tests, bloques duplicados y un montón de data muy interesante en un dashboard muy sencillo de usar.

    Originalmente, esta herramienta la configuré para mantener un estándar en los proyectos de Automation, para revisar el código y dar coscorrones a los que no estén haciendo las cosas bien. Se ve que algunos equipos dev gustaron de lo que vieron y decidieron usarla también, lo cuál me vino como anillo al dedo para mis planes de conquista mundial, los cuales eran muy muy inocentes.

    La primer idea que tuve fue decir "bueno, ya que tenemos todas esta información servida en bandeja de plata, usemos esto en beneficio de Testing! Agarro las métricas de los proyectos Dev, miro cuáles son los repos con menos estabilidad, con más riesgo y de ahí tomo para planificar según eso y los intereses del business las próximas suites de Automation". La idea enseguida encantó a los Managers y me dieron luz verde para seguir desarrollándola. 

    La segunda idea fue decir "bueno...ya que voy a empezar a tener una colaboración con los devs, aunque sea a través de Sonarqube porque todavía no me consideren su amigo, voy a intentar también hacer que las builds de Jenkins sean ejecutadas de una forma más eficiente que la actual. Y para eso, voy a añadir WebHooks en sus repositorios que, al detectar cambios mandados al Master, disparen las suites de jobs en Jenkins que yo especifico". De nuevo, Management me aplaudía como una foca en Seaworld. 

    El problema: buscando construir la columna de Babel...

    El problema apareció por un lado que no esperaba. Cuando salí a hablar con los equipos de desarrollo para poner en marcha pruebas de concepto...resultó que la gran mayoría del código de las aplicaciones NO EXISTIA EN LA EMPRESA. Así es...todo estaba en la nube, bajo la celosa mirada de diferentes vendors que eran los creadores y que no tenían ningún interés en dejar que otros metan sus narices en sus asuntos. 

    Entonces de repente no se iba a poder incluir el 80% de proyectos en la idea de Sonarqube porque simplemente no teníamos control ni manera de pedirles que hagan eso. La segunda idea que se fue por la borda fue, de forma similar, la que les mencioné de los Webhooks y la ejecución "inteligente" de jobs en Jenkins. Ya no había control sobre los repos de los devs. 

    Supongo que entiendo el por qué. Es introducir algo que "no te beneficia a vos", al decir todo lo que está mal con el código que escribiste. Por qué alguien querría meterse en semejante embrollo sin ningún beneficio? Y es esa mentalidad lo que me llevó a la...

    Conclusión: De nada sirve hablar de calidad si no es un enfoque holístico.

    DevOps es acerca de la cultura de la empresa o del proyecto. Es sobre el concepto de que "todos somos responsables de la calidad del producto". A veces, cuando se trabaja en una empresa grande, con muchísimos contractors, vendors y otras yerbas haciendo buena parte del trabajo, esa comunicación y loop de feedback se hacen más pequeño o incluso se pierde. DevOps es sobre amplificar el feedback en cada etapa del desarrollo de software para mejorar las decisiones todo el tiempo. 

    Dado que hoy en día es muy común que las empresas grandes tengan mucho tercerizado, creo que acá radica el principal problema de DevOps y el cuál, en mi opinión, se puede resolver mediante el uso de herramientas con un enfoque objetivo sobre el cuál trabajar. Vean el caso de Sonarqube sino. No soy yo apuntando con el dedo y diciendo a los desarrolladores de esa otra empresa "competencia" de la mía que su código es una bazofia, es la colección de hechos arrojados por el análisis de una aplicación. 

    En ese sentido, se evitan las asperezas que puedan surgir de tener que interactuar para comunicar esas cosas y se trabaja sobre los fríos hechos y datos arrojados por el monitoreo de una herramienta.

    Creo que es, pienso yo, cuestión de establecer esas herramientas como algo mandatorio para incluso aquellos que tengan su código en la Luna. De esa manera no hay misterios, ni lagunas, ni cosas libradas a la imaginación y todos estamos trabajando en una misma dirección. 

    Y ustedes? Qué opinan? Les pasa algo parecido en sus lugares de trabajo? Dejen sus comentarios que los leo!




  • Sonarqube y Automation: Apuntando los cañones en la dirección correcta.


    Listo el café, lista la manta...momento de escribir desde el crudo invierno en la ciudad de Wellington, Nueva Zelanda! Por nuestras tierras latinas seguramente están pasando frío también, así que voy a mantener el berrinche al mínimo.

    Hoy les quería hablar de una herramienta que le encuentro una utilidad muy importante, sobre todo cuando está bien implementada y se usa bien por el equipo de desarrollo. Esa herramienta es Sonarqube.

    Qué es Sonarqube?

    Sonarqube es una herramienta de análisis estático que, dados unos parámetros de qué estándar de calidad esperamos de nuestro código, nos va a decir la salud del repositorio al que lo apuntemos. Rebobino un poco para aquellos que no estén familiarizados con el término análisis estático, lo cuál es de lo más normal no saber si venís del mundo de Testing. 

    Los reportes son muy visuales y fáciles de digerir.

    El análisis estático es la revisión del código, sea de la aplicación bajo test o del mismo proyecto de Automation, mediante el cual se detectan errores, code smells, vulnerabilidades, duplicación y otras cosas que hacen del código algo potencialmente peligroso y/o imposible de mantener a largo plazo. 

    Dos ejemplos simples que he visto: 

    Un campo password con el String sin encriptar. Esto Sonarqube te lo remarca como una vulnerabilidad por ejemplo. De ahí podes usar algo como Jasypt, en Java, para encriptar dicha clave y luego ese análisis debería pasar para esa parte. 

    Otro caso puede ser el de un Switch Case sin la declaración de un Default para los cases. Esto Sonarqube lo levanta como un Code Smell. Sobre el tufo en el código voy a hablarles más largo y tendido en otro post, pero es algo que deberían empezar a familiarizarse ya que, queramos o no, estamos codificando y es necesario pensar como dev...A VECES!

    Cómo se usa normalmente Sonarqube?

    Generalmente, Sonarqube se usa justamente para eso: Realizar el análisis estático sobre un repositorio dado y, en base a los resultados, empezar a refactorear el código para dejarlo más mantenible, sin errores, evitando duplicación y, a fin de cuentas, achicando la deuda técnica. 

    En equipos de Automation, Sonarqube se suele usar para exactamente lo mismo. Realizar un análisis estático sobre el código que se escribe. Pero...es realmente necesario? Se le puede dar otros usos desde la mirada de Testing? Yo creo que si y es justamente sobre lo que les quiero hablar hoy!

    Primero que nada, quiero aclarar por qué yo personalmente no me inclino por esta herramienta para analizar los proyectos de Automation en sí y por qué, en mi opinión, hay un mejor uso para darle en el que todos salimos ganando y aumentando los círculos de feedback en etapas tempranas del desarrollo, cosa que va de la mano con las prácticas DevOps que tantos hablan y pocos implementan de forma correcta. 

    Cada cosa encontrada suele tener el justificativo y cómo solucionarlo.

    Sonarqube es una herramienta con licencia paga. La licencia paga permite analizar branches entre otras cosas. Así es...adivinaste: La licencia gratuita solo permite analizar el master de nuestro repositorio. En el ciclo de Automation, llegar a los errores y deuda técnica recién después de haber hecho un push, pull request, teniendo personas que dieron el OK y finalmente habiendo hecho el merge me parece algo contraproducente. 

    No quiero esperar a haber mergeado los cambios en el master para que la herramienta me diga "che, la pifiaste como un campeón y te lo digo recién ahora". Para eso considero mejor contar con buenas prácticas de pull requests y merges, sumado a buenas políticas y estándar de código. 

    Pero...qué otro uso le puedo dar?

    Algo que estoy empezando casualmente esta semana es este uso que les voy a comentar ahora: Digamos que tenemos la aplicación bajo test, siendo desarrollada por el equipo dev. Ellos usan Sonarqube para analizar estáticamente su código en el master, para asegurarse que producción esté limpio a pesar de haber hecho los pull requests y merges meticulosamente. Porque bueno, los devs cometen errores. 

    Sonarqube analiza todas esas líneas de código y genera este hermoso reporte diciendo qué porcentaje de coverage hay con Unit Tests, cuánta duplicación de código, bugs, code smells, vulnerabilidades y otras bellezas que harían tener pesadillas a cualquier Manager Técnico

    Nosotros, desde el equipo de Automation (o incluso Testing manual), tomamos esa información y decimos: Bueno, en función de ésto, parece que el módulo para la autenticación tiene potenciales fallas dado el alto número de Code Smells que se encontró. Deberíamos enfocar los tests en esta área para dar una buena cobertura. 

    De repente...qué pasó? Ya no estamos planificando a ciegas. No estamos intentando adivinar dónde van a estar los defectos. Todos sabemos que testear TODO es imposible muchas veces por temas de tiempo y dinero. En ese caso a qué acudimos? Al Testing basado en el riesgo de cada módulo. Y de dónde sacamos este índice de riesgo de cada módulo? Vamos a ir a preguntar al equipo dev dónde creen que metieron la pata más? Imposible! Pero teniendo de nuestro lado la información provista por esta herramienta de análisis estático, estamos ante una mina de oro para la planificación. 

    Conclusión: Algo digno de probar! 

    Esto es algo que voy a estar probando en las próximas semanas y los estaré actualizando sobre cómo va. Los animo a que prueben hacerlo en sus proyectos, sobre dado que es una herramienta que cuenta con una licencia gratuita. Si trabajan codo a codo con los desarrolladores, propongan su uso, configuren y vean el reporte que les da. En base a eso reúnanse, hagan un brainstorming y salgan con un plan de tests a automatizar por prioridad y riesgo! 

    Dejen sus comentarios si ya usaron esta herramienta, si piensan usarla o si usan alguna otra para análisis estático!

  • Las mejores prácticas no existen!

    Quieto quieto! Tranquilo! Puedo notar como más de uno está saltando a mi yugular ahora mismo! Pero si, ustedes saben que me gusta hablar de casos del mundo real y de mis experiencias. Y hoy toca contarles cómo dos de los artefactos de Test más valiosos de mi actual cliente (que es ENORME), no siguen ninguna de las mejores prácticas y nunca dieron un solo problema.

    Primero...qué son las mejores prácticas y por qué son importantes?

    Bueno, las mejores prácticas son básicamente la voz de la experiencia que dice cómo deberíamos hacer las cosas en un contexto dado. Esto es para hacerlo de la manera más eficiente, con menor cantidad de problemas y que sea de fácil mantenimiento en el futuro. Siempre hablando desde la posición de Automation, claro está. 

    Pero ahí mismo hay un problema: Este contexto dado, que es un requerimiento fundamental diría yo para poder aplicar las mejores prácticas, no siempre es lo que tenemos en nuestro lugar de trabajo. Es más, me atrevería a decir que nunca es el caso. De ahí a que haya tanto problema conque "Agile no sirve", "DevOps es una mentira!", "Automation es puro humo" y otras frases que vamos a escuchar y leer a menudo. 

    Si tenemos la suerte de estar ante esta situación, lo que mejor podemos hacer es seguirlas. Pero es un arma de doble filo que, cuando NO estamos en la situación ideal...puede llevar a infinitos dolores de cabeza y un desastre atrás de otro para el proyecto. 

    En el caso de Automation, sabemos que hay un par de decisiones lógicas que podemos tomar y vamos a estar seguros: Usar el Page Object Model para modelar el código y hacerlo más mantenible y reutilizable. Automatizar siempre que podamos en la capa de WebServices en lugar de la UI para evitar la fragilidad que tiene esta última...ustedes saben, lo conocido. 

    Pero entonces...por qué decís que te fue mejor sin seguir estas mejores prácticas?

    No es que me fue mejor en general, sino que dos de las últimas soluciones que implementé, sus artefactos de Testing, fueron engendros opuestos a todo lo que se conoce como Best Practices. Les paso a contar.

    El primero de ellos fue para ayudar a alguien. Resulta que en su equipo, tenían que hacer cientos de llamadas a un WebService a diario para testear un componente de seguridad. Por un tema de tiempos y expertise del ingeniero de test de turno, no se podía hacer un framework a tiempo con Rest Assured porque implicaba el ramp up del recurso y la incertidumbre de si iba a poder hacerlo o no. 
    La solución fue crear jobs en Jenkins con los comandos cURL que el ejecutaba y programarlos para que se corran todos los días antes de que él llegara. Con un poco de toqueteo para que el console output tuviese algo de sentido. Básicamente eran cientos de cURL con sus grep para validar el cuerpo de lo que respondía el servidor. 

    Esa solución se implementó y le sacó las papas del fuego justo a tiempo. Anduvo tan bien que no hubo prioridad en mover todo eso a un framework apropiado con Rest Assured, cosa que se está haciendo recién ahora por insistencia mía. Si...me gustan las mejores prácticas, no crean que no!

    El otro artefacto se puso algo más complejo. Resulta que trabajo para un cliente muy importante, con medidas de seguridad MUY estrictas, por lo que la red interna en la que se ejecuta es una selva de proxies, firewalls, puertos que si, puertos que no, Mutual TLS, Kerberos...en fin, ustedes me entienden, un montón de cosas que hacen que el más sencillo de los tests sea una odisea. 

    El requerimiento era que se pudiese ejecutar un tests muy sencillo de logueo para hacer el flow similar del cliente. Pero...también tenía que medir el tiempo de login, el tiempo de carga de la página, el tiempo de logout y plasmar todo eso en un Dashboard de Grafana. 

    Para sumar felicidad, esto se iba a ejecutar desde una plataforma en la nube, externa. Por lo que tenía que entregar un artefacto que corra y listo. Nada de clonar, buildear...directo a los bifes.

    La primera cosa que pensé fue "bueno...uso JMeter porque para medir tiempos qué mejor, no?". Pero la cuestión era que tenía que hacer mímica de un cliente, por lo que el renderizado de la página y todo lo que es JavaScript no iba a ser contemplado en el muestreo. Había que hacer otra cosa...

    Selenium iba a tener que ser...no quedaba otra! Para los muestreos del tiempo tenía una librería que exportaba el HAR y de ahí podía parsear, hacer un baile místico y sacar los tiempos. Pero...los tiempos eran tiranos, no querían todo el framework que tan lindo creé para usar como template y los requerimientos de la plataforma en la nube eran bastante estrictos. 

    Vuelta a JMeter! Sobre todo porque tiene una integración muy feliz con influxDB y de ahí es sencillo consultar la data desde Grafana para construir el tan ansiado Dashboard del cliente. Pero no podía ser API, porque quería ser como un cliente. Así que si...metí Selenium en JMeter. Y no solo eso, PhantomJS (obsoleto hoy en día) en lugar de ChromeDriver en modo headless porque no podían añadir ChromeDriver al estar prohibido por el proxy. Un amor. 

    Así que creé un solo JMX, en el que tenía una sola clase con todo el flow de login. Pasaba por la página principal, navegación a la de Login, validación en la landing y luego un logout. 3 Páginas diferentes....no Page Object Model a la vista. 

    Eso se ejecutaba y, al tener la clase dividida en bloques, era fácil sacar los tiempos que tardó cada uno con JMeter y escribir eso en influxDB gracias a la integración que les contaba más arriba. 

    Resultados

    Este último ejemplo es, hoy en día, el asset de Automation que más se usa en todo el cliente. Está en cada piso, en cada pantalla gigante que veo. Con managers y gente de las altas esferas usando eso para monitorear la actividad y anticiparse a cambios inesperados en la performance o errores a través de los distintos ambientes...incluso Producción! 

    Y lo mejor...no requirió mantenimiento alguno en más de medio año. Es un script sencillo, que hace algo muy importante en valor para los managers y ejecutivos, con una integración algo intrincada para acercarles un resultado fácil de interpretar para personas no técnicas. 

    Y si...nada de ésto sigue las mejores prácticas, pero como les decía: Las mejores prácticas solo son las mejores en contexto. Muchas veces van a necesitar ser flexibles y no hacer las cosas de una manera solo porque "las mejores prácticas lo dicen". Especialmente si esto lleva a que empeore el mantenimiento! Este, amigos lectores, es uno de los errores que con más frecuencia veo en el mundo de Automation. 

    Nunca dejen de aprender! 
  • CONSULTA POR LOS CURSOS Y CONTENIDO

    Enviá tu consulta o sugerencia sobre qué te gustaría ver en la comunidad.

    EMAIL

    thefreerangetester@gmail.com