Una historia de Testing

Crecer como comunidad y compartir conocimientos valiosos para extender mejores prácticas que ayuden a elevar el nivel de la industria del software es parte de nuestra misión como empresa. Por eso, invitamos a Julio César Pérez Arques, Engineering Manager, a dirigir una sesión desde nuestro meetup en la que buscamos dar luz sobre el Testing y cómo implantarlo de manera efectiva en un equipo. A través de su experiencia, nos contó el recorrido que siguió para transformar un equipo desmotivado y con entregas fallidas en uno que aportaba valor real a sus clientes y se sentía orgulloso de su trabajo. 

La historia de Julio comienza cuando trabajaba como jefe de un equipo de desarrollo en una consultoría. El sistema del equipo era waterfall, con fases muy definidas de entrada y salida y con un sistema jerárquico en el que cada rol se dedicaba a una tarea específica. Al poco tiempo, se dio cuenta de que este funcionamiento no generaba valor para el equipo ni para los clientes, ya que la manera de trabajar estaba basada en entregas no testeadas que posteriormente presentaban múltiples incidencias que había que corregir. En realidad, el equipo vivía en un constante ciclo de dolor: efectuaban entregas fallidas, luego resolvían ciertos errores y volvían a entregar, pero después aparecían otros errores que había que volver a corregir y así sucesivamente. Como consecuencia, el equipo experimentaba mucho estrés y desmotivación, ya que carecía de confianza en sus capacidades y estaba acostumbrado a limitarse a "tapar huecos". A su vez, los clientes perdían fiabilidad en las entregas y quedaban insatisfechos con los proyectos.

En este contexto, Julio se planteó el inicio de un nuevo camino con 3 puntos claves:

• Ser capaces de hacer un working software: que funcione y que aporte valor.
• Desarrollar de manera iterativa e incremental, con pasos más pequeños y mayor feedback para aportar valor real a los usuarios. 
• Implantar testing automatizado.

Julio tenía muy claro que era necesario un cambio de cultura, había que generar un ambiente en el que la responsabilidad, colaboración y la excelencia técnica fueran parte intrínseca del equipo para que los desarrolladores pudieran sentirse orgullosos de su código y de su trabajo. El camino fue largo y, en ocasiones, hubo resistencia al cambio, pero la clave estuvo en la adopción de buenas prácticas técnicas que ayudaron a cambiar los procesos y la mentalidad del equipo. 

“Yo no soy un gran programador. Sólo soy un buen programador con grandes hábitos”.
- Kent Beck

En este proceso de cambio, el testing automatizado era clave para hacer un working software y para implementar un desarrollo iterativo e incremental, ya que había que ser capaz de probar todas las entregas de manera rápida, sencilla y a bajo coste. Sin pruebas o sin las suficientes pruebas, las entregas, aunque sean pequeñas versiones, iban a tener bugs o errores que les harían regresar al ciclo de dolor al que no querían volver.

Según explico el manager, el primer paso para implantar tests automatizados fue aprender a diseñar software testeable, que tuviera alta cohesión y bajo acoplamiento, y en esta línea saber sobre clean code, solid e inyección de dependencias. También era necesario tener la teoría clara, conocer lo que era un buen test y aprender sobre mocking y frameworks de testing.  

“Un buen diseño es también un diseño testable”.
- Julio César Pérez Arques

Claro que, como mencionamos anteriormente, el cambio no fue fácil y surgieron varios problemas en el camino. Julio mencionó algunos de ellos y cómo superarlos:

• Resistencia por parte de miembros del equipos. Al principio es difícil superar esta etapa, pero rápidamente salen a la luz los beneficios de utilizar buenas prácticas, ya que el código que se genera funciona y es de mayor calidad. A su vez, se reduce el estrés del equipo y aumenta el sentimiento de orgullo.
• La falsa creencia de que los test ralentizan el proceso de creación de software. En este punto el manager explica que la velocidad en el desarrollo de software consiste en conseguir que el software funcione sin errores y que los usuarios puedan realmente utilizarlo.
• ¿Qué probar con testing? No se puede probar al 100%, hay que decidir en función de la confianza que se ganará haciendo un test frente al coste de hacerlo.
• Los test se rompen. Hay que aprender a hacer buenos test y tener en cuenta los anti-patrones que son malas prácticas en las pruebas. 

Un buen test es rápido, confiable y no debe depender del estado de servicios externos. Debe ser fácil de leer y modificar, y relevante, que pruebe algo significativo y que añada valor.

Brevemente Julio habló sobre el Test Driven Development y mencionó que hay que tener claro que no es una técnica de testing, es una técnica de desarrollo que incluye diseñar, programar y probar.  No vas a diseñar mejor simplemente por hacer TDD, pero sí vas a tener unos momentos claros en su flujo de funcionamiento para pensar en el diseño. 

En conclusión, gracias al cambio que se generó en el equipo, tanto en la cultura como en el uso de mejores prácticas técnicas, pudieron empezar a construir un software que funcionaba con los siguientes beneficios: 

• Detección temprana de errores
• Confianza en el código, no del 100% pero sí un aumento significativo
• Mejores diseños de software
• Mayor productividad del equipo 
• Documentación real de códigos 
• Desarrollo iterativo e incremental

En definitiva, el equipo comenzó a enorgullecerse de su trabajo y su nivel de motivación aumentó, lo que también les permitió afianzarse con sus clientes y crear un mejor ambiente de trabajo. 

Agradecemos a Julio César por esta sesión y su contribución a la comunidad. También a la colaboración de Murcia Software Crafters por participar como facilitadores del encuentro. Y para los que quieran repasar conceptos y revisar la sesión completa aquí les dejamos un enlace al vídeo:

Revisa también nuestro meetup relacionado sobre el desarrollo iterativo e incremental: