[05/03/2020] Probar las aplicaciones solía ser una actividad técnicamente desafiante y corta de tiempo, programada días o semanas antes del lanzamiento de una aplicación. A los equipos de desarrollo se les daba margen de maniobra para codificar hasta la hora undécima, y los evaluadores, que hacían gran parte de su trabajo manualmente, no tenían más remedio que arreglárselas con el poco tiempo que se les daba. El resultado fue que muchas aplicaciones se sometieron a pruebas de calidad inferior, y los equipos de tecnología se vieron obligados a responder a los problemas y defectos de producción que se acentuaron con usuarios finales y los sistemas de monitoreo de aplicaciones.
Las prácticas de integración continua de Devops, los frameworks de pruebas de unidades y las prácticas de automatización de pruebas han alterado este paradigma. En lugar de realizar un aseguramiento de calidad al final del proceso de desarrollo, muchas prácticas de prueba ahora comienzan y se ejecutan completamente durante la codificación, integración e implementación. Los equipos de Devops y agile automatizan los scripts de prueba, y las tuberías de CI/CD avisan para ejecutar las pruebas durante sus fases de integración de código o entrega. El resultado neto es que los desarrolladores reciben una alerta cuando los cambios en el código rompen la compilación y pueden tomar medidas inmediatas para abordar el problema informado.
La automatización de pruebas e integración de scripts de prueba en pipelines de CI/CD se conoce como shift-left testing. Implica que se puedan realizar más prácticas de garantía de calidad en la fase de desarrollo, para detectar problemas más temprano en la línea de tiempo de lanzamiento. La automatización de las pruebas es una de las prioridades previas a la implementación para los equipos agile y Devops 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. Luego, estas pruebas se pueden automatizar e incluir en los pasos de compilación o implementación. En lugar de que los ingenieros de QA 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 hacia la izquierda desde el final del proceso de lanzamiento a fases de desarrollo y codificación anteriores.
Shift-left testing hace posible el compromiso de los equipos agile con la calidad
Shift-left testing no solo impulsa la eficiencia y mejora la calidad, sino que también crea un cambio cultural significativo en el proceso de desarrollo agile.
Algunos equipos de desarrollo perciben la garantía de calidad y las pruebas como una barrera en el proceso de que el código llegue a producción. Después de todo el trabajo duro para satisfacer a los propietarios de productos agile y completar el código, los compañeros del equipo de QA identifican una lista de errores que requieren corrección. Si QA encuentra muchos errores, puede influir la línea de tiempo de lanzamiento para corregirlos. Peor aún es cuando secciones importantes del código necesitan reingeniería porque las fallas exponen problemas de lógica, seguridad o rendimiento. En este escenario, los desarrolladores y e ingenieros de QA pueden estar en el mismo equipo agile pero no actúan como uno.
Shift-left testing permite a los equipos agile transferir las responsabilidades de calidad al equipo completo de desarrolladores y evaluadores. Cuando las pruebas se ejecutan como parte del pipeline de CI/CD, ofrece 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 tubería de CI/CD alerta al desarrollador de la compilación fallida, y la mayoría de los equipos de desarrollo autoorganizados requieren solucionar de manera inmediata estos problemas.
Shift-left testing también les brinda oportunidades a los desarrolladores e ingenieros de QA para automatizar más pruebas. Una buena 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 de unidad y API, pero los ingenieros de automatización de QA muchas veces desarrollan pruebas de experiencia de usuario end-to-end y pruebas de transacciones que simulan llamadas API de múltiples pasos a múltiples servicios.
Cuándo aplicar shift-left testing
Shift-left testing funciona mejor para las pruebas atómicas a nivel de unidad que tienen tiempos de ejecución cortos. Es esencial que las pruebas automatizadas en el pipeline de CI/CD, y que se ejecutan siempre que los desarrolladores activan una compilación, corran 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 end-to-end, las pruebas de transacciones, el análisis de código estático y las pruebas de seguridad, a menudo se ejecutan mejor fuera de los pipelines de CI/CD y en horarios diarios o más frecuentes. Estas pruebas aún les brindan retroalimentación temprana a los desarrolladores sobre problemas de calidad, pero son automatizadas fuera de CI/CD para evitar ralentizaciones o embotellamientos.
Thomas J. Sweet, vicepresidente de servicios de TI en GM Financial, compartió conmigo sus ideas personales sobre los límites de las estrategias de shift-left testing. Sugiere: "Shift-left siempre es una estrategia, excepto cuando se realizan pruebas de integración en entregas de terceros, ya que a menudo no se tiene acceso a su código fuente. Incluso cuando uno cuenta con aplicaciones internas con arquitecturas monolíticas heredadas, puede comenzar aplicando políticas básicas de check-in que requieren una revisión de código y un escaneo de seguridad. El check-in debe rechazarse si el escaneo incluye advertencias y fallas esenciales”.
Una posible solución para las pruebas en fases 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 en fase posterior a diferentes inputs. Funciona bien cuando los sistemas en fase posterior están bien definidos. Herramientas de Micro Focus, Tricentis, y otros habilitan esta capacidad.
Rob Pociluk, un gerente de control de calidad altamente experimentado, es un firme defensor de shift-left testing en el desarrollo agile. "Estar listo y ser capaz de probar pequeñas secciones de código mantiene el QA flexible y actualizado durante el progreso de un sprint. Aun así, los equipos deben evitar usar demasiado shift-left testing, ya que se puede perder el propósito del código en sí mismo”.
Por lo tanto, incluso cuando los equipos adoptan por completo shift-left testing, existen buenas razones para programar una ventana de prueba en una compilación de código completo destinada a su lanzamiento. Esto asegura que todas las pruebas automatizadas se realicen en la compilación final, pero también permite programar pruebas adicionales que requieren un sistema completamente funcional.
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 proporcionan comentarios. Se puede hacer algo de UAT durante el desarrollo, pero es posible que no sea fácil que las personas realicen estas pruebas con frecuencia o cuando la funcionalidad no está completamente lista.
Requisitos previos para las estrategias de shift-left testing
Shift-left testing es una práctica creciente de DevOps que tiene sus requisitos previos y requiere una inversión inicial. Se requieren algunas capacidades y prácticas esenciales.
- Se necesitan suficientes capacidades y entornos de prueba para soportar la cantidad de compilaciones y pruebas que se ejecutan simultáneamente.
- Los equipos agile requieren un conjunto de herramientas de productos de prueba que se integren fácilmente en los pipelines de CI/CD y en 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 infosec, líderes de QA y otros miembros senior 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 entrada 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 previamente, los equipos de scrum, incluidos los ingenieros de automatización de pruebas de QA, 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 tuberías de CI/CD e identificar cuando los pasos de prueba automatizados afectan la productividad. Los equipos de Devops a menudo requieren cronogramas de pruebas adicionales fuera de las tuberías de CI/CD para ejecutar pruebas de mayor duración.
- Los equipos deben discutir regularmente las lagunas en sus pruebas automatizadas, especialmente las validaciones que requieren expertos en la materia, UAT o pruebas con socios. Si los equipos agile no pueden abordar estas brechas con la automatización, entonces los ciclos de lanzamiento se deben tener en cuenta en los gastos generales para reducir los riesgos y completar estas pruebas.
Por último, los equipos agile y las organizaciones de Devops deberían medir y discutir regularmente su cobertura de prueba. Emplear una estrategia de shift-left testing no funciona si los equipos de desarrollo y los ingenieros de automatización de calidad en realidad no implementan, automatizan e integran pruebas suficientes para detectar problemas y abordar los riesgos.
Acelerar los ciclos de lanzamiento o permitir la entrega continua sin una automatización de prueba suficiente puede dar lugar a problemas de calidad significativos que degradan la experiencia de los usuarios finales. Los equipos de desarrollo agile que sacan lanzamientos con demasiada frecuencia se encuentran abordando problemas y defectos de producción en lugar de invertir en más y mejor automatización.
Isaac Sacolick, InfoWorld (EE.UU.)
Isaac Sacolick es el autor de Driving Digital: The Leader's Guide to Business Transformation through Technology, que abarca muchas prácticas como la metodología ágil, devops y ciencia de datos, consideradas fundamentales para el éxito de los programas de transformación digital. Sacolick es un CIO social reconocido, un bloguero de vasta experiencia en Social, Agile and Transformation y CIO.com, también es presidente de StarCIO.