¿Qué es la prueba de cambio a la izquierda? ¿Y qué significa para DevOps?

La metodología de pruebas de desplazamiento a la izquierda es un enfoque para las pruebas de software que aporta los requisitos de pruebas anteriormente en el ciclo de desarrollo de software.

 

El desarrollo de software ha visto una evolución bastante en las últimas décadas. Hoy en día, los ingenieros y evaluadores de rendimiento pueden integrar cualquier número de herramientas de automatización, aprendizaje automático e inteligencia artificial en sus pruebas. No fue hace mucho tiempo cuando las pruebas de software eran una nota secundaria. De hecho, el desarrollo temprano del software ni siquiera tenía una fase de prueba formal. La introducción de las pruebas no se hizo hasta que el software se volvió más complejo, donde los errores y defectos del entorno de producción comenzaron a afectar al negocio. Los desarrolladores llevaron a cabo las pruebas ellos mismos, no un equipo separado. Así es como las pruebas funcionales surgieron y se convirtieron en parte del modelo de cascada tradicional, que consiste en etapas separadas (Análisis, Requisitos, Diseño, Codificación, Pruebas, Aceptación, Producción y Postproducción) que se movieron a través de una ruta lineal, similar a una línea de montaje en una fábrica.

Waterfall Model de Paul Hoadley. Utilizado bajo la licencia Creative Commons.

 

Una vez completada cada etapa, pasó al siguiente grupo y se movió hacia abajo. Se veía bien en papel, pero QA no probando el código hasta después de que la mayoría de estas etapas se completaron. Por lo tanto, esto significaba que quedaba muy poco tiempo para realizar modificaciones en el código antes de la producción. Si el problema o error era lo suficientemente grave, eso significaba desechar o retrasar el proyecto. Por otra parte, esto significó una enorme pérdida potencial para las empresas, dependiendo de la importancia de la aplicación de software.

 

Cambiar las pruebas a la izquierda – Colocación de la fundación

Afortunadamente, las costosas lecciones aprendidas de errores de desarrollo anteriores ayudaron a marcar el comienzo del método de cambio a la izquierda. Las organizaciones se dieron cuenta de que identificar problemas al final del juego no sólo era demasiado costoso, sino también arriesgado. Un artículo de TechRepublic de mayo de 2019 informó que el costo promedio anual para corregir errores visuales en el software es de más de $400,000. No es exactamente un cambio tonto.

Además, la industria en su conjunto estaba cambiando. Hubo una transformación digital con la que las empresas tenían que lidiar. Las organizaciones empezaban a darse cuenta de que ya no podían confiar en uno o dos ciclos de lanzamiento al año. Las expectativas y demandas de los clientes eran altas. Liberar un producto mal diseñado significó perder clientes ante la competencia. Algo tenía que cambiar.

Las organizaciones comenzaron a dividir el ciclo de desarrollo en bloques más pequeños y manejables e incorporar pruebas en cada fase. Esto permitió un entorno más colaborativo, dando a los equipos la capacidad de identificar problemas antes. Por ejemplo, al comprender mejor los requisitos de software anteriormente en el proceso, los equipos de pruebas podrían ayudar a desarrollar mejores casos de prueba para corregir cualquier posible error. Esto también se conoce como «fallar temprano y a menudo» o «fallar rápido». La consideración de los escenarios de usuario y el comportamiento de software anteriormente en el proceso elimina los posibles errores y optimiza el código. Esto permite a los equipos entregar un producto consistente.

Obviamente, va a haber momentos en los que las pruebas simplemente no tienen sentido. Por ejemplo, no puede llevar a cabo pruebas de GUI hasta que tenga una GUI. Sin embargo, el cambio a la izquierda es más una mentalidad, no sólo un proceso de desarrollo. Lo más importante es que los equipos siempre deben pensar en lo que haría una mejor experiencia de usuario. En última instancia, es el usuario que va a tener el producto final en sus manos. Cualquier cosa que pueda mejorar una aplicación antes de que se inserte en producción beneficia a todos.

 

El auge de las pruebas de cambio a la izquierda y Agile y DevOps

Debido al aumento de los avances tecnológicos y el enfoque en la experiencia digital, se produjo un cambio de paradigma. Los ciclos de desarrollo y pruebas se hicieron más cortos y frecuentes. Esto dio lugar a que las nuevas características se introdujn en el mercado antes. Lo más importante es que esto no sólo permitió a las empresas mantenerse competitivas, sino que mantuvo a los clientes felices y comprometidos. Por ejemplo, las aplicaciones móviles y web suelen funcionar en ciclos de lanzamiento de dos semanas. Algunas organizaciones lanzan actualizaciones diariamente – o incluso por hora!

El enfoque para el desarrollo de aplicaciones y software es ser rápido, ágil y reducir el riesgo. Las organizaciones están enfrentando este desafío a través del desarrollo de software ágil y las prácticas de DevOps. El desarrollo de software ágil es similar al modelo de cascada; sin embargo, la diferencia clave es que en un modelo de cascada, siempre hay una fase de prueba después de la fase de diseño. El método Agile divide el desarrollo en pequeñas iteraciones, llamadas sprints, que ya no duran cuatro semanas. Cada sprint implica que los miembros del equipo multifuncionales trabajen en todos los aspectos del sprint, con pruebas completadas en cada iteración. Esto permite una mayor colaboración entre los miembros del equipo, ciclos de retroalimentación más cortos y un producto de mayor calidad.

Y ese es otro factor importante sobre las pruebas de desplazamiento a la izquierda. En las pruebas tradicionales de cascada, la responsabilidad de probar y administrar la calidad del producto recae en el equipo de control de calidad. En las pruebas de cambio a la izquierda y en los entornos ágiles, los desarrolladores y evaluadores llevan a cabo las pruebas reales, pero la responsabilidad recae en todo el mundo debido a su enfoque colaborativo y multifuncional durante el desarrollo. Hoy en día, hay cuatro enfoques diferentes para cambiar las pruebas a la izquierda: tradicional, incremental, ágil/devOps, y pruebas de desplazamiento a la izquierda basadas en modelos.

 

Tipos de pruebas de cambio a la izquierda

En los últimos años, el término DevOps se ha convertido en una palabra de moda para marketing, productos de software e incluso descripciones de trabajos. En pocas palabras, DevOps es un marco alternativo dentro del enfoque ágil que tiene como objetivo reunir a los equipos de desarrollo y operaciones. Históricamente, cada departamento tenía sus respectivos objetivos, a veces contradictorios. Los desarrolladores crean, diseñan e innovan. Los equipos de operaciones se centran en la infraestructura y en «mantener las luces encendidas» con un monitoreo continuo para garantizar la disponibilidad. Del mismo modo, DevOps se creó específicamente para lograr más colaboración, comentarios y agilidad entre estos departamentos. También se hace referencia a DevOps cuando se habla de CI / CD (integración continua y despliegue continuo) y automatización, pero el hecho de que una organización use CI / CD y automatización, no los hace automáticamente certificados por DevOps.

 

Prácticas recomendadas de pruebas de carga para entornos DevOps

Si sus equipos siguen un enfoque obsoleto de pruebas de carga y monitoreo, DevOps puede empujarlo rápidamente a un desastre de rendimiento. Los equipos de control de calidad tienen que lidiar con implementaciones de nuevas versiones frecuentes. Los equipos de DevOps necesitan una manera fácil de administrar sus pruebas, además de una supervisión flexible, para proporcionar información adecuada.

Pruebas de carga continua.

Hay demasiados cambios que pueden afectar a la interfaz de usuario y bloquear la prueba de carga. El enfoque inicial debe ser ejecutar pruebas de API totalmente automatizadas y programar su ejecución a diario. Una vez que los procesos empresariales clave son estables, puede agregar pruebas de extremo a extremo adicionales a su escenario de pruebas

Comparta información valiosa.

Involucre a su equipo de DevOps en las actividades de análisis de resultados. No practiques la ocultación de información. Comparta todas las pruebas de carga (incluidas las pruebas de carga de Selenium) y los resultados de monitoreo con sus ingenieros para determinar la causa de todos los problemas.

Monitoreo de todas las capas.

Cambiar a la izquierda también significa tener un monitoreo similar a la producción en las etapas de Desarrollo y control de calidad. No tendrá tiempo para reproducir continuamente errores en canalizaciones de desarrollo ágiles. Asegúrese de recopilar métricas de uso de infraestructura, front-end y front-end 24/7 para etapas que no son de producción.

Línea de base y punto de referencia.

Las pruebas de carga continua producen toneladas de datos. Establezca líneas de base y utilice puntos de referencia para detectar desviaciones al principio del ciclo. Cuanto antes conozcas las desaceleraciones, más tiempo tendrá tu equipo de desarrollo para solucionar estos problemas.

 

Integración de las pruebas de rendimiento en la metodología Shift Left

Las aplicaciones actuales utilizan múltiples tecnologías, que dependen de vastas redes de proveedores externos y CDN. Añada al hecho de que los usuarios pueden acceder a sus aplicaciones desde cualquier lugar del mundo, desde cualquier número de dispositivos, todo ello con diferentes velocidades de conexión. Eso es mucho para tener en cuenta cuando se trata de dar a los usuarios una gran experiencia todo el tiempo. Los tiempos de respuesta, la calidad y la disponibilidad son factores críticos que necesitan atención antes de llevar las aplicaciones a la producción.

Una vez en producción, su aplicación o sitio tendrá que soportar hasta cientos, o incluso miles de usuarios simultáneos. Los cambios pequeños e incrementales en el código pueden afectar al rendimiento, por lo que cuanto antes pueda encontrar errores relacionados con el rendimiento, más fácil y menos costoso será corregirlos. En la mayoría de los casos, los equipos deben ser capaces de solucionar cualquier problema de rendimiento dentro de uno o dos días. Una vez más, es mucho más fácil llevar a cabo esas mejoras entonces, en comparación con descubrirlas antes de la implementación.

Idealmente, una vez que el código ha pasado por las pruebas funcionales necesarias, con características examinadas y aprobadas, los equipos deben ejecutar pruebas no funcionales, como pruebas de esfuerzo y carga, para ver qué tan bien los artefactos de prueba funcionales resisten a los usuarios virtuales. LoadView juega una parte integral del enfoque de prueba de cambio a la izquierda, permitiendo a los usuarios tiempo, dinero y entregar código y aplicaciones optimizados.

 

La plataforma LoadView: pruebas de carga basadas en la nube en navegadores reales

La plataforma LoadView es una plataforma de pruebas de carga flexible que puede abordar el problema de patrones de carga ineficaces, simulando todo, desde pruebas basadas en protocolos hasta pruebas reales basadas en navegador. Está completamente basado en la nube, por lo que no es necesario configurar e implementar inyectores de carga internos, administrar cuentas en la nube de terceros o preocuparse por los requisitos de hardware o software. Las pruebas de rendimiento generalmente requieren infraestructura y recursos adicionales que algunas organizaciones pueden no ser capaces de soportar. LoadView administra esto por usted a través de la plataforma.

LoadView es ideal para probar código o servicios web temprano para ayudar a comparar las características de rendimiento, ya que puede girar fácilmente y simular altos niveles de carga en el backend desde un solo inyector de carga, ahorrándole tiempo y dinero en comparación con otras herramientas. Esto lo hace ideal para probar arquitecturas de API web como JSON, SOAP y REST. Además, las pruebas no funcionales suelen requerir tiempos de configuración más largos y scripts complejos que requieren que los desarrolladores e ingenieros tengan conocimientos prácticos de lenguajes de programación específicos. Esto a veces puede ser difícil de automatizar, ya que tienden a funcionar solo en un ecosistema específico del proveedor. Este no es el caso con LoadView.

 

Scripting Facilite: The EveryStep Web Recorder

LoadView utiliza una grabadora de scripts fácil de usar llamada EveryStep Web Recorder. Los usuarios pueden crear fácilmente acciones avanzadas de scripting que simulan acciones reales del usuario con sus API, aplicaciones web y sitios web. Para validar los tiempos de respuesta de extremo a extremo para las aplicaciones del lado cliente, los usuarios pueden simplemente navegar por su caso de prueba y registrar cada acción. Comprender la cantidad de carga que una API o aplicación web puede controlar durante la fase de desarrollo temprana puede ayudar a los desarrolladores en estas áreas críticas:

• Determinar las líneas base de tiempo de respuesta bajo números de carga de usuario específicos
• Identificación de cuellos de botella de rendimiento
• Encontrar límites superiores de sus sistemas actuales para la planificación de la capacidad
• Análisis del rendimiento del servidor (CPU, memoria, ancho de banda, E/S de disco) y tiempos de respuesta de la base de datos

La grabadora también es compatible con más de 40 navegadores y dispositivos de escritorio/móviles populares, así como tecnologías web y lenguajes de programación, como AJAX, HTML5, JavaScript, Flash, Silverlight y más. LoadView utiliza estos scripts para ejecutar pruebas de esfuerzo y carga bajo demanda, desde más de 13 ubicaciones globales (Estados Unidos, Canadá, América del Sur, Europa y APAC), proporcionando a los ingenieros de pruebas datos de rendimiento del mundo real de navegadores reales. Recuerde que la ejecución de una prueba interna puede indicarle qué tan bien la aplicación o el sitio gestiona un aumento del tráfico desde su propia red, pero nunca reflejará las condiciones del mundo real. Las aplicaciones y los sitios que no se han probado y optimizado correctamente pueden afectar negativamente a las conversiones y, en última instancia, a los ingresos.

 

LoadView: Flexibilidad para probar escenarios del mundo real

LoadView ofrece a los usuarios la opción de distribuir la carga de usuarios entre ubicaciones geográficas en función del porcentaje de tráfico a su sitio. Por ejemplo, si sabe que un determinado porcentaje de sus clientes y usuarios proceden de una ubicación geográfica específica, puede seleccionar esas áreas específicas para probar. La plataforma utiliza Amazon Web Services (AWS) y Azure Cloud Services para generar usuarios virtuales. Además, los usuarios pueden llevar sus pruebas de carga un paso más allá personalizando el tipo de curva de carga. Esto proporciona una flexibilidad aún mayor para los ingenieros de pruebas, dependiendo de su escenario único. Los usuarios de LoadView pueden elegir entre tres curvas de carga diferentes:

Curva de paso de carga

• • Comienza con un número predeterminado de usuarios simultáneos y aumenta gradualmente la carga para ver cómo su sitio web puede manejar un pico de tráfico y compararlo con el tráfico esperado.

Curva basada en objetivos

• • Este tipo de curva de carga es útil cuando ya ha determinado el objetivo de rendimiento o el número de visitantes a su sitio durante un intervalo de tiempo fijo. Ideal para validar SLA o requisitos no funcionales.

Curva ajustable dinámica

• • Esta prueba permite a los usuarios ajustar la carga mientras se ejecuta la prueba para descubrir los límites de rendimiento de los sitios web o la capacidad del servidor.

Una vez finalizadas las pruebas, LoadView genera automáticamente informes que ayudan a los equipos a medir el éxito de sus KPI (indicadores clave de rendimiento), como el número de usuarios simultáneos, errores, tiempos de respuesta promedio, uso de CPU, rendimiento, latencia y mucho más. Estas métricas son fundamentales para los desarrolladores, Las operaciones de desarrollo y los equipos de control de calidad, ya que ayudan a descubrir cuellos de botella del mundo real que podrían afectar potencialmente al rendimiento del usuario final.

 

Después de cambiar a la izquierda, no olvide cambiar a la derecha

Con todo el enfoque en las pruebas de desplazamiento a la izquierda, es difícil recordar que hay otro paso extremadamente importante en el proceso que recibe menos atención. Después de que la aplicación entre en producción, debe asegurarse de que todo siga funcionando sin problemas para los usuarios. Dotcom-Monitor ofrece múltiples soluciones de monitoreo para garantizar que sus páginas y aplicaciones continúen funcionando y funcionando correctamente.

Supervisión de Servicios Web

• • Tiempo de actividad y rendimiento de servicios web, como HTTP/S, SOAP/REST y más

Monitoreo de páginas web

• • Rendimiento de la página web en navegadores reales, identificando elementos más lentos y rápidos a lo largo del tiempo

Supervisión de aplicaciones web

• • Supervise aplicaciones web complejas, como AJAX, PHP, Ruby, Flash y más

Monitoreo de infraestructuras

• • Funcionalidad y rendimiento de servidores y protocolos de Internet, como HTTP/S, correo electrónico, streaming multimedia, VoIP y más

Estas plataformas permiten a los usuarios configurar la supervisión continua basada en umbrales personalizados y pueden alertar a individuos o equipos específicos cuando se producen errores para que puedan trabajar en solucionar problemas antes de afectar a muchos más usuarios.

 

Cambiar las pruebas a la izquierda: Bueno para los negocios y la tranquilidad

En conclusión, los conceptos de cambio a la izquierda y de desplazamiento a la derecha pueden ser extremadamente valiosos, no sólo dentro del ciclo de desarrollo de software, sino también dentro de otros departamentos e industrias. Por ejemplo, los gerentes de producto o los gerentes de experiencia del cliente están «cambiando a la izquierda» y se están involucrando con más frecuencia con los clientes reales para obtener comentarios continuos. Esto permite a las organizaciones ser más ágiles y acercarse a la fuente de información y comentarios para comprender mejor a sus clientes. Sólo piénsalo. ¿No sería más probable que trabajara con alguien o continuara haciendo negocios con una empresa que valora su opinión? Por lo tanto, ahora cuando escuchas a alguien decir, «cambio a la izquierda» o «prueba temprano y a menudo», no es sólo una palabra de moda elegante que están lanzando alrededor. Es una pieza crítica del rompecabezas de la experiencia del cliente y uno que siempre debe mantener en la parte posterior de su mente. No solo sus usuarios y clientes estarán contentos, sino que obtendrá eficiencias, logrará mejores resultados y le dará tranquilidad a usted y a su organización.