Trae tus propias herramientas… Pero primero, piénsalo dos veces
Los equipos de software tienen más libertad que nunca. Tienen acceso a una amplia variedad de herramientas, y muchas de ellas son gratuitas. Existe una abundancia de componentes de código abierto disponibles para crear aplicaciones. Y lo mejor de todo es que muchos empleadores animan a los equipos a configurar sus propios sistemas de desarrollo, metodologías y que los miembros del equipo aporten sus propias herramientas.
La libertad de usar las herramientas, métodos y tecnologías que más te gustan y mejor conoces probablemente contribuya de manera positiva a la productividad de tu equipo… hasta que llegas al límite de la autosuficiencia del equipo.
Evita un cuello de botella en las pruebas
Mi amigo, Jan, lideraba un equipo de software muy competente en una empresa de desarrollo de software a medida. Realmente sabían cómo ser ágiles. Y tenían un problema de calidad. Aceleraron tanto su ciclo de lanzamientos que las pruebas se convirtieron en un cuello de botella.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Y resolvieron el cuello de botella saltándose las pruebas. Jan, por supuesto, entendió lo que había que hacer. Descargó Robot Framework, lo usó para crear un marco personalizado de automatización de pruebas para el equipo, y lo integró en su flujo de integración continua. Gradualmente, fue añadiendo más y más pruebas y amplió el marco con una gran cantidad de palabras clave de alto nivel para facilitar la escritura de pruebas.
Mientras tanto, los demás equipos—y había muchos de ellos—experimentaban desafíos similares y los resolvían a su manera, con Selenium o alguna herramienta de su elección.
Los equipos necesitan un marco de automatización para todos
Los pesimistas dicen que toda solución contiene la semilla de un nuevo problema. Pronto Jan se dio cuenta de que se había convertido en un ingeniero de automatización de pruebas a tiempo completo. Claro, sus bibliotecas eran fáciles de usar—para él, y su arquitectura de pruebas era fácil de entender—para él. En cada uno de los otros equipos, había un compañero en la misma situación. Uno de ellos cambió de trabajo. El desarrollador que asumió el puesto decidió reescribir todo porque no le gustaba cómo se había construido la automatización y le resultaba difícil de entender. A medida que muchos equipos empezaban a informar de estos desafíos a sus gerentes, surgió la pregunta obvia: ¿por qué no hay coherencia entre los equipos?
Había que hacer algo. La solución era evidente: establezcamos un equipo centralizado de automatización de pruebas que sirva a los equipos de desarrollo proporcionando un único marco de automatización para todos. En la práctica, el equipo eran Jan y otro desarrollador. Aquí fue cuando comenzó la verdadera lucha.
Comparte la metodología, no solo las herramientas
Las pruebas fallaban con frecuencia. También fallaba el marco de trabajo. A los equipos de desarrollo les costaba cambiar sus prácticas para adaptarse a las herramientas, y al equipo de herramientas le costaba acomodar todas esas necesidades diferentes. La complejidad del marco seguía aumentando. El cuello de botella en las pruebas había sido sustituido por un cuello de botella en las herramientas de automatización de pruebas.
Compartir herramientas internas es una idea excelente, pero es difícil hacer que funcione. Para tener éxito, la herramienta debe gestionarse como un producto real y debe ser probada adecuadamente. Paradójicamente, los marcos de automatización de pruebas internos suelen tener errores. Pero hay un reto aún mayor. Para beneficiarse de las herramientas compartidas a gran escala, también se necesita una metodología compartida.
La historia de Jan es típica—y no ha terminado aún. Ahora están contemplando su próximo paso: volver a los equipos autónomos y aceptar el coste, invertir más en las herramientas compartidas y establecer una metodología coherente, o elegir una herramienta comercial y centrarse solo en la metodología. Ninguna de estas opciones es incorrecta, pero cada una de ellas tendrá diferentes consecuencias.
