Te va a interesar!

6/recent/ticker-posts

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!

Publicar un comentario

0 Comentarios