El pasado jueves día 17 de septiembre celebramos en la empresa en la que trabajo una nueva edición del Open Space de Tecnología. Se presentaron 23 posibles temas para tratar, de los cuales finalmente hablamos de 12 temas. Los temas eran bastante variados, algunos relacionados con horarios, desarrollo profesional y equipos de desarrollo dinámicos, con movimiento de miembros de un equipo a otro. Otros temas estuvieron relacionados con cómo sincronizar mejor la parte tecnológica con el negocio, y cómo ser más ágiles, no en un sentido de desarrollo ágil, sino de ser suficientemente ágiles durante los desarrollos para que estos avancen y no se queden bloqueados o parados.
En cuanto a los temas más relacionados con calidad y pruebas de software, se presentaron varios temas. Hablamos de smoketests, y de de la importancia de aumentar el número de pruebas, haciendo que cada equipo, en cada desarrollo, incluyera los smoketests como parte de la tarea. Por supuesto, para lograr esto sería necesario que el equipo de QA forme a los distintos equipos en cómo utilizar y desarrollar los smoketests.
También hablamos, como no puede ser de otra forma en este tipo de reuniones, de entornos, y de la importancia de tener entornos de prueba fiables. Este es un tema problemático en casi cualquier desarrollo, y yo por mi parte os remito a lo que dije anteriormente sobre Gestión / Control de entornos en el artículo Pilares para construir software con calidad.
Otro tema muy interesante fue el que se presentó con el título “No, si esta consulta no tarda”, y cuya descripción era: “Amazon (dice) que aumentó sus ingresos un 1% por cada 100 ms mejorados en la carga de las páginas, Google lo tiene en cuenta para posicionar al indexar… ¿Como podríamos integrar pruebas de performance en los ciclos de release para intentar mejorar nuestros tiempos de respuesta?”. En este caso hablamos de las distintas opciones que teníamos para realizar pruebas de software, desde usar herramientas como ab (Apache HTTP server benchmarking tool), JMeter o HP LoadRunner Community Edition. Por supuesto, además de herramientas, también es necesario tener entornos de pruebas comparables a los de producción, para que las mediciones realmente sirvan para algo.
Otra herramienta interesante de la que hablamos fue TestNG, un framework de pruebas inspirado en JUnit y NUnit, pero con funcionalidades muy interesantes que lo hacen disponer de más capacidades, además de ser más fácil de usar. Sin duda merece la pena investigarlo y probarlo.
Sin duda se trató de una gran experiencia, en la que se trataron muchos temas interesantes, de una forma relajada y muy participativa. Hubo temas muy interesantes que se quedaron fuera, como el de “Ansible + Vagrant ¿Es interesante la filosofía de recetas?” o “Simplificación tecnológica y optimización”, pero había que elegir, y creo que los temas que finalmente se trataron estuvieron muy bien.
Para quién no conozca los principios de un Open Space podéis echarle un vistazo a la siguiente imagen, o visitar el enlace anterior.
