Cómo mejorar CI / CD con pruebas de desplazamiento a la izquierda

Probar aplicaciones solía ser una actividad técnicamente desafiante y con poco tiempo, programada días o semanas antes del lanzamiento de una aplicación. A los equipos de desarrollo se les dio margen de maniobra para codificar hasta la undécima hora, y los probadores, que hicieron gran parte de su trabajo manualmente, no tuvieron más remedio que conformarse con el poco de tiempo que se les dio. El resultado fue que muchas aplicaciones se sometieron a pruebas deficientes y los equipos de tecnología se vieron obligados a responder a los problemas de producción y los defectos escalados por los usuarios finales y los sistemas de monitoreo de aplicaciones.

Las prácticas de integración continua de Devops, los marcos de pruebas unitarias y las prácticas de automatización de pruebas han cambiado este paradigma. En lugar de realizar el control de calidad al final del proceso de desarrollo, muchas prácticas de prueba ahora comienzan y se ejecutan por completo durante la codificación, la integración y la implementación. Los desarrolladores y los equipos ágiles automatizan los scripts de prueba, y las canalizaciones de CI / CD llaman para ejecutar las pruebas durante las fases de integración o entrega del código. El resultado neto es que los desarrolladores reciben una alerta cuando sus cambios de código rompen la compilación y pueden tomar medidas inmediatas para abordar el problema informado.

La automatización de las pruebas y la integración de scripts de prueba en las canalizaciones de CI / CD se conoce como prueba de desplazamiento a la izquierda. Implica que se pueden realizar más prácticas de aseguramiento de la calidad en la fase de desarrollo para detectar problemas antes en el cronograma de publicación. La automatización de las pruebas es una de las prioridades previas a la implementación para los equipos ágiles y de desarrollo que desean aumentar las frecuencias de implementación.

En la introducción de la nueva funcionalidad, los scripts de prueba construidos validan las nuevas capacidades. Estas pruebas se pueden automatizar e incluir en los pasos de compilación o implementación. En lugar de que los ingenieros de control de calidad ejecuten pruebas de regresión al final de un proceso de lanzamiento, puede ejecutar y validar muchas de estas pruebas como parte del desarrollo. Estas pruebas se desplazan a la izquierda desde el final del proceso de lanzamiento hasta fases anteriores de desarrollo y codificación.

Las pruebas de cambio a la izquierda permiten el compromiso de los equipos ágiles con la calidad

Las pruebas de cambio a la izquierda no solo impulsan la eficiencia y mejoran la calidad, sino que también crean un cambio cultural significativo en el proceso de desarrollo ágil.

Algunos equipos de desarrollo perciben la garantía de calidad y las pruebas como una barrera para que su código se entregue en producción. Después de todo el arduo trabajo para satisfacer a los propietarios de productos ágiles y completar el código, los miembros del equipo de control de calidad identifican una lista de errores que requieren corrección. Si QA encuentra muchos errores, puede afectar el cronograma de lanzamiento para corregirlos. Aún peor es cuando es necesario rediseñar secciones importantes del código porque las fallas exponen problemas de lógica, seguridad o rendimiento. En este escenario, los desarrolladores y los ingenieros de control de calidad pueden estar en el mismo equipo ágil pero no actúan como un equipo.

Las pruebas de cambio a la izquierda permiten que los equipos ágiles transfieran las responsabilidades de calidad al equipo completo de desarrolladores y probadores. Cuando la prueba se ejecuta como parte de la canalización de CI / CD, brinda una mejor oportunidad para que los desarrolladores aborden los problemas de calidad en el momento en que están trabajando en el código relevante. La canalización de CI / CD alerta al desarrollador sobre la compilación fallida y la mayoría de los equipos de desarrollo autoorganizados requieren solucionar estos problemas de inmediato.

Las pruebas de cambio a la izquierda también brindan a los desarrolladores e ingenieros de control de calidad oportunidades para automatizar más pruebas. Una mejor práctica es que los equipos decidan quién implementa la automatización en función de los tipos de pruebas requeridas para la funcionalidad desarrollada. Por ejemplo, los desarrolladores a menudo son responsables de automatizar las pruebas unitarias y de API, pero los ingenieros de automatización de QA a menudo desarrollan pruebas de transacciones y pruebas de experiencia de usuario de un extremo a otro que simulan llamadas API de varios pasos a varios servicios.

Cuándo aplicar la prueba de cambio a la izquierda

Las pruebas de cambio a la izquierda funcionan mejor para las pruebas atómicas más a nivel de unidad que tienen tiempos de ejecución cortos. Es esencial que las pruebas estén automatizadas en la canalización de CI / CD, y que se ejecuten cada vez que los desarrolladores activen una compilación, se ejecuten rápidamente y no ralenticen los procesos de compilación.

Las pruebas más complejas y que requieren mucho tiempo, como las pruebas de experiencia de usuario de un extremo a otro, las pruebas de transacciones, el análisis de código estático y las pruebas de seguridad, a menudo se ejecutan mejor fuera de las canalizaciones de CI / CD y en programas diarios o más frecuentes. Estas pruebas aún brindan retroalimentación temprana a los desarrolladores sobre problemas de calidad, pero están automatizadas fuera de CI / CD para evitar compilaciones ralentizadas o con cuello de botella.

Thomas J. Sweet, vicepresidente de servicios de TI en GM Financial, compartió conmigo sus conocimientos personales sobre los límites de las estrategias de prueba de desplazamiento a la izquierda. Sugiere: “Desplazar a la izquierda es siempre una estrategia, excepto cuando se realizan pruebas de integración en entregas de proveedores externos, ya que a menudo no se tiene acceso a su código fuente. Incluso cuando tiene aplicaciones internas con arquitecturas monolíticas heredadas, puede comenzar aplicando políticas de registro básicas que requieren una revisión de código y un escaneo de seguridad. El registro debe rechazarse si el análisis incluye advertencias y fallas esenciales ".

Una posible solución para las pruebas posteriores con socios de integración es implementar la virtualización de servicios. Esta técnica permite a los equipos de desarrollo simular la respuesta de un sistema aguas abajo a diferentes entradas. Funciona bien cuando los sistemas posteriores están bien definidos. Las herramientas de Micro Focus, Tricentis y otros permiten esta capacidad.

Rob Pociluk, un gerente de control de calidad con mucha experiencia, es un firme defensor de las pruebas de cambio a la izquierda en el desarrollo ágil. “Estar listo y ser capaz de probar pequeñas secciones de código mantiene el control de calidad flexible y en el ciclo durante el progreso de un sprint. Los equipos aún deben protegerse contra el uso de shift-left demasiado, ya que puede perder el propósito del código en sí ".

Por lo tanto, incluso cuando los equipos adoptan completamente las pruebas de cambio a la izquierda, existen buenas razones para programar una ventana de prueba en una compilación de código completo destinada a su lanzamiento. Garantiza que todas las pruebas automatizadas se realicen en la compilación final, pero también permite programar pruebas adicionales que requieren un sistema en pleno funcionamiento.

Una de esas pruebas es UAT (prueba de aceptación del usuario), donde los usuarios finales seleccionados y los expertos en la materia validan y brindan comentarios. Se pueden realizar algunas UAT durante el desarrollo, pero puede que no sea fácil lograr que las personas realicen estas pruebas con frecuencia o cuando la funcionalidad no esté completamente lista.

Requisitos previos para las estrategias de prueba de desplazamiento a la izquierda

Las pruebas de cambio a la izquierda son una práctica de DevOps en crecimiento, pero tiene sus requisitos previos y una inversión inicial. Se requieren algunas capacidades y prácticas esenciales.

  • Se necesitan entornos y capacidad de prueba suficientes para admitir la cantidad de compilaciones y pruebas que se ejecutan al mismo tiempo.
  • Los equipos ágiles requieren un conjunto de herramientas de productos de prueba que se integren fácilmente en las canalizaciones de CI / CD y las herramientas de programación de trabajos, y que puedan validar la funcionalidad, la calidad del código, la seguridad y el rendimiento.
  • Los arquitectos, especialistas en seguridad de la información, líderes de control de calidad y otros miembros de alto nivel de la organización deben establecer estándares de prueba y objetivos de nivel de servicio que formen los criterios de aceptación predeterminados.
  • Cuando las aplicaciones requieren la participación del usuario, los equipos de prueba necesitan suficientes datos y patrones de prueba para validar suficientes personas, casos de uso y patrones de entrada.
  • En el compromiso de sprint o antes, los equipos de scrum, incluidos los ingenieros de automatización de pruebas de control de calidad, deben establecer una estrategia de prueba sobre qué capacidades se prueban, qué tipos de pruebas se implementan, qué procesos de automatización se actualizan y quién desarrolla las pruebas.
  • Los equipos de Devops deben medir la duración de las ejecuciones de la canalización de CI / CD y señalar cuándo los pasos de prueba automatizados afectan la productividad. Los equipos de Devops a menudo requieren programas de pruebas adicionales fuera de las canalizaciones de CI / CD para ejecutar pruebas de mayor duración.
  • Los equipos deben discutir periódicamente las lagunas en sus pruebas automatizadas, especialmente las validaciones que requieren expertos en la materia, UAT o pruebas con socios. Si los equipos ágiles no pueden abordar estas brechas con la automatización, los ciclos de lanzamiento deben tener en cuenta los gastos generales para reducir los riesgos y completar estas pruebas.

Por último, los equipos ágiles y las organizaciones de DevOps deben medir y discutir regularmente la cobertura de sus pruebas. Emplear una estrategia de prueba de cambio a la izquierda no funciona si los equipos de desarrollo y los ingenieros de automatización de la calidad no implementan, automatizan e integran pruebas suficientes para detectar problemas y abordar riesgos.

Acelerar los ciclos de lanzamiento o permitir la entrega continua sin la suficiente automatización de las pruebas puede generar problemas de calidad importantes que degraden la experiencia de los usuarios finales. Los equipos de desarrollo ágiles que impulsan lanzamientos con demasiada frecuencia se enfrentan a problemas y defectos de producción en lugar de invertir en una mayor y mejor automatización.