El objetivo de este artículo es resaltar la importancia de la fase de Test dentro del ciclo infinito de DevOps, y repasar las herramientas, los frameworks y los métodos, los tipos de pruebas y un panorama del ecosistema de AWS y los servicios disponibles para implementar las buenas prácticas de DevOps y, en particular, la fase de Test. No es un artículo técnico, sino más bien uno general e informativo. No vas a encontrar detalles técnicos sobre cómo configurar un pipeline ni cómo desplegar el código en tu infraestructura, sino una explicación de los puntos clave, las opciones y los servicios involucrados.
La fase de Test
Las prácticas de DevOps exigen entregas rápidas de software, con la posibilidad de hacer varios despliegues por día. Para cumplir con estos requisitos, los equipos tienen que poder probar el código en cuestión de minutos y con la mayor frecuencia posible. La fase de Test determinará si el build está listo para pasar a la siguiente etapa o si se bloquea con base en los resultados de las pruebas, sin intervención humana.
Probar el software es un paso esencial dentro del Software Development Life Cycle (SDLC): poder detectar bugs de forma temprana y resolverlos antes del release a producción tiene un valor enorme. Incluir una fase de Test en tu pipeline aporta el gran beneficio de identificar bugs existentes. En esta fase se usan herramientas de testing automatizado, que varían según la aplicación. Por ejemplo, herramientas como Newman son una forma sencilla de probar los métodos públicos de tu API; JUnit/Xunit o Jest son ideales para las pruebas unitarias de tu código o componentes; y Playwright o Cypress son perfectas para implementar pruebas e2e completas hasta el nivel de UI si tu aplicación es web.
La fase de Test también es el momento en el que puedes integrar herramientas de gestión de pruebas como TestRail. Esta herramienta genera reportes completos sobre el codebase y los resultados de las pruebas, y le da a los stakeholders visibilidad sobre el ciclo de desarrollo y la madurez de la aplicación. Estas capacidades les permiten a los stakeholders de tu empresa contar con reportes que les ayudan a entender mejor el ciclo de desarrollo y la madurez del producto. Vale la pena adoptar la mentalidad de que la calidad vive en toda la organización y no solo dentro de los límites del departamento de QA. Esa mentalidad te ayudará a alcanzar los mejores resultados, y la fase de Test será el camino para lograrlo.
Por qué la fase de Test es importante
El beneficio más importante y crítico de la fase de Test es que permite que las pruebas, la validación de calidad y la evaluación de rendimiento ocurran lo antes posible dentro del SDLC. Esta práctica de shift left rompe con el testing tradicional o manual, que suele suceder al final del ciclo.
Estos son algunos beneficios evidentes de la fase de Test:
- Implementar pruebas de forma temprana en el SDLC habilita un proceso de testing continuo, lo que permite entregas más rápidas y constantes de software. Este enfoque facilita probar de forma rápida, frecuente y temprana, y reduce el riesgo de que los errores pasen desapercibidos.
- Automatizar las pruebas elimina el factor humano de pasar por alto errores, aunque implica el mantenimiento y la actualización de los escenarios de prueba. En consecuencia, puede ser necesario contar con un equipo de developers dedicado al testing.
- Cada paso del SDLC involucra distintas formas de testing (pruebas unitarias, pruebas de API, e2e y UI). Esto reduce la necesidad de retroceder cuando se detecta un error.
Implementar esta fase reduce el tiempo de entrega de las aplicaciones y minimiza errores y bugs, lo que ayuda a establecer un modelo de responsabilidad compartida en torno a la calidad, donde todo el departamento de Engineering responde por la calidad de la aplicación.
Sobre la pirámide de testing
La pirámide de testing es un concepto muy conocido en el desarrollo de software y se ha discutido en distintos artículos y publicaciones, pero la descripción original la hizo Mike Cohn en su libro Succeeding with Agile. La metáfora de la pirámide ayuda a visualizar las distintas capas de testing que deberían implementarse en el desarrollo de software.
Las pruebas Behavior-Driven son las más efectivas, ya que incorporan escenarios de prueba y resultados esperados. Estas pruebas asumen que cubren la integración entre componentes, lo que convierte a las pruebas de integración en las más valiosas, ya que validan el sistema como un todo o en módulos aislados y complejos, en lugar de unidades individuales. Por eso podría parecer que invertir en pruebas e2e de UI (que se ejecutan sobre el sistema una vez desplegado e integrado por completo) es una gran idea, lo cual es cierto. Pero también tiene sus trampas; por ejemplo, contar únicamente con pruebas e2e de UI puede llevar a un gasto desproporcionado, dolores de cabeza de mantenimiento y mucho estrés.
Invertir exclusivamente en pruebas end-to-end de UI suele derivar en el antipatrón conocido como "cono de helado" en la pirámide de testing, también llamado pirámide atípica o invertida.
El mantenimiento de este cono se vuelve una pesadilla, los costos pueden dispararse, los resultados de las pruebas pueden volverse inconsistentes y tu organización probablemente perderá los beneficios de una fase de Test bien hecha.
Ahora podemos repasar las capas de la pirámide de testing, los tipos de pruebas más comunes y los beneficios de cada uno.
- Pruebas unitarias: las más básicas y granulares, enfocadas en una unidad de trabajo, normalmente un método o un componente. Estas pruebas viven en la base de la pirámide y pueden compilarse y ejecutarse dentro de tu etapa de Build. Son fáciles de implementar, son baratas y ofrecen una primera línea de defensa para la calidad del código.
- Pruebas de integración / pruebas de API: la integración se hace mediante la API, así que probar esta capa es crucial para tus sistemas. Estas pruebas tienen que validar la capacidad del sistema para funcionar de manera integrada (es decir, validar que las unidades de trabajo pueden coexistir e interactuar entre sí). Pueden implementarlas los developers o los especialistas de calidad, según la estructura organizacional. Al final del día, nadie querría subirse a un avión que solo tuvo pruebas unitarias.
La automatización de pruebas es…
Cuando tienes una cantidad cada vez mayor de software, o incluso si es bastante estático, vas a tener serias dificultades para probar tu aplicación de forma manual. Asegurarte de que un proceso repetitivo se haga correctamente y reducir el factor de error humano es prácticamente imposible cuando se hace de forma manual. Aquí es donde la automatización entra al rescate. La automatización se ha vuelto un estándar en casi todo, desde la infraestructura hasta la orquestación de tus builds y la prueba de tu código y aplicaciones.
En la práctica, esto significa que los developers se enfocarán en escribir pruebas unitarias y de integración como parte de sus entregables o tareas, mientras que los especialistas de calidad se enfocarán en escribir las pruebas e2e de UI con base en los escenarios proporcionados por el negocio o los product owners. La fase de descubrimiento de pruebas, hecha principalmente con testing manual, se realiza como etapa previa a la automatización.
Para automatizar la fase de Test puedes usar alguna de las herramientas disponibles hoy en el mercado. Las posibilidades son infinitas y dependen sobre todo de tus necesidades y de las habilidades de tu organización de desarrollo. Playwright y Cypress te ayudarán a alcanzar los objetivos enfocándose en pruebas e2e de UI; ambas tienen ventajas y desventajas, y hoy en día incluso puedes usarlas como una solución todo-en-uno (probando todas las capas de tu pirámide) si tu stack es JS, por ejemplo. Otra capa es la de integración, donde la variedad de herramientas también es amplia: Katalon, Newman de Postman y otras. Siempre revisa las características y considera la complejidad, la interoperabilidad y la capacidad de integrarse con un pipeline de CI/CD (ya que el propósito mismo de tenerlas es poder integrarlas en tu fase de Test, lo que significa incluirlas en tu pipeline de CI/CD). Por último, pero no menos importante, está la capa de pruebas unitarias. Para escribirlas y ejecutarlas necesitas usar las herramientas que mejor se adapten a tu codebase: para código en .Net puedes usar XUnit, para Java usa JUnit y para código escrito en JS o TS puedes usar Jest (o, como mencioné antes, herramientas como Playwright son modernas y versátiles, y si tu codebase está en JS o TS puedes usar Playwright para probar toda la pirámide. Consulta la documentación oficial de Playwright).
AWS CodePipeline para implementar tu fase de Test
La fase de Test puede implementarse con distintas herramientas y servicios disponibles hoy en el mercado. Servicios como Jenkins y CircleCI te permiten ejecutar los mismos pasos para alcanzar los resultados deseados: necesitas obtener tu código del repositorio > Compilarlo > Probarlo > Desplegar a Pre-Producción (Staging) > Opcionalmente probar de nuevo > Desplegar a Producción. Y listo, el despliegue terminó.
Existen muchas herramientas y servicios, pero hablemos de los servicios de AWS. AWS CodePipeline es un servicio de continuous delivery (CD) totalmente administrado que ayuda a construir pipelines, orquestar etapas y entregar actualizaciones a tu aplicación e infraestructura. AWS CodePipeline funciona muy bien con otros servicios DevOps de AWS como AWS CodeDeploy, AWS CodeCommit y AWS CodeBuild, así como con proveedores externos conocidos como Jenkins y Github.
El caso de uso simple para el pipeline es: obtener el código > Compilarlo > Desplegarlo. Suena sencillo, y en este caso solo puedes ejecutar las pruebas unitarias en la etapa de Build del pipeline. ¡Genial! Pero ¿qué pasa cuando tienes un pipeline más complejo donde la fase de Test incluye pruebas de integración e incluso pruebas e2e de UI? El pipeline se vería así: obtener el código > Compilarlo > Desplegar a Staging > Probarlo > Desplegar a Producción. La diferencia es que, al extender el pipeline, agregamos la etapa de testing que puede ejecutar pruebas de integración o pruebas e2e de UI contra nuestro entorno de Staging desplegado en la etapa anterior. ¡Mucho mejor! Agregar la fase de Test aquí es tan directo como añadir el paso adicional (Stage) desde la página de edición del pipeline existente y configurar la ejecución de tus pruebas con el framework de testing nativo (según la herramienta que tengas).
Como este servicio es versátil y puede interactuar con muchos otros servicios de AWS y de terceros, es difícil elegir uno solo como ejemplo, pero vale la pena mencionar algunas funcionalidades útiles e importantes de AWS CodePipeline:
Detection option: es una propiedad del pipeline que lo inicia y, según la ubicación de origen de los artefactos, AWS recomienda usar webhooks de Github para Github o Amazon CloudWatch Events para artefactos almacenados en un bucket de AWS S3, por ejemplo.
Disable/Enable transition: la transición conecta las etapas del pipeline y está habilitada por defecto. Si por alguna razón no quieres pasar automáticamente de una etapa a otra, puedes deshabilitarla con el botón "Disable transition", lo que evita la ejecución continua del pipeline. Volver a habilitarla es muy fácil.
Add Stage: para editar la secuencia del pipeline e introducir una nueva etapa o eliminar/actualizar una existente, debes hacer "Edit" sobre el pipeline, lo que te llevará a la página de edición donde puedes agregar acciones a tu etapa de forma serial o en paralelo a las acciones existentes. Esta funcionalidad hace que tu pipeline sea flexible y extensible.
Approval Action: cuando quieres gestionar las etapas de tu pipeline, por ejemplo que alguien apruebe la etapa de despliegue, puedes usar esta funcionalidad, que detiene el pipeline hasta la aprobación y reanuda la ejecución una vez que esta ocurre.
Otros servicios DevOps de AWS con los que CodePipeline funciona e integra muy bien son:
- AWS CodeCommit
- AWS CodeDeploy
- AWS CodeBuild
Resumen y conclusión
Ningún pipeline debería existir sin una fase de Test, y ningún release debería existir sin una fase de Test. Minimiza el factor humano y apóyate en la automatización y en las herramientas disponibles para lograrlo: ese debe ser el foco del especialista DevOps responsable del CI/CD. Y no solo del especialista DevOps que probablemente construirá el pipeline, sino de toda la organización de desarrollo, incluidos los developers, el personal de QA y el equipo de DevOps. El enfoque correcto es ver la calidad como una responsabilidad de todos y a la fase de Test como una etapa disponible, conveniente, flexible y a prueba de balas. ¡Usar el servicio adecuado, como AWS CodePipeline, te ayudará a alcanzar los resultados deseados!
Enlaces y recursos: