Cómo optimizar las pruebas de rendimiento con un enfoque de cambio a la izquierda

Descubra cómo cambiar las pruebas de rendimiento a la izquierda en toda su organización.

Cada sprint es fundamental y las decisiones que se toman en el futuro son muy rápidas. Para facilitar el proceso de retroalimentación rápida, los equipos de prueba deben validar minuciosamente sus aplicaciones, de un extremo a otro, en un período de tiempo muy corto. Para maximizar este esfuerzo, los equipos de pruebas pueden modernizar su enfoque de las pruebas para obtener el mejor retorno de la inversión posible en las primeras etapas posibles de las pruebas de software.

¿Qué es la prueba de rendimiento Shift-Left?

Cambiar las pruebas de rendimiento a la izquierda significa permitir que los desarrolladores y evaluadores realicen pruebas de rendimiento en las primeras etapas de los ciclos de desarrollo. Tradicionalmente, las pruebas de rendimiento son una tarea que se realiza al final de los ciclos de desarrollo porque requiere un conjunto de herramientas y habilidades especializadas, es decir, hardware costoso en entornos dedicados por ingenieros de pruebas de rendimiento capacitados. En cambio, una estrategia de prueba de rendimiento de cambio a la izquierda permite que los evaluadores realicen pruebas de rendimiento ad hoc más pequeñas contra componentes individuales a medida que se desarrollan.

Para lograr esto, los equipos deben comenzar a crear pruebas de rendimiento junto con pruebas unitarias y funcionales, cuando se implementa la funcionalidad, y configurar esas pruebas de rendimiento para que se ejecuten automáticamente e informen de una manera que le advierta sobre disminuciones en el rendimiento. Para ejecutar las pruebas automáticamente, la ejecución de la prueba de rendimiento debe estar estrechamente integrada como parte del proceso de CI / CD, en el que después de cada verificación de código, las pruebas de rendimiento se ejecutan en entornos locales junto con las pruebas funcionales y unitarias.

Este proceso permite a las organizaciones comprender el impacto sutil de los nuevos componentes que se agregan al rendimiento agregado de su aplicación y, en última instancia, permite el descubrimiento de defectos relacionados con el rendimiento mucho antes en el ciclo de vida de la entrega. Desde la perspectiva de la cultura de la empresa, cambiar las pruebas de rendimiento a la izquierda también significa involucrar más a los desarrolladores. En la mayoría de los casos, los equipos de desarrollo pueden realizar mejoras de optimización un día después de descubrir la degradación del rendimiento, en lugar de esperar hasta que se compile toda la aplicación.

¿Qué tiene que hacer la organización para que suceda el desempeño de Shift-Left?

1. En primer lugar, necesita una aceptación organizativa bien establecida. Abordar la calidad como un proceso y no como una reacción es esencial para cambiar las pruebas de rendimiento que quedan en toda la empresa. Los jugadores clave en este proceso son los gerentes de producto porque las pruebas de rendimiento y el tiempo de desarrollo asociado tienen un costo de implementación, lo que puede ralentizar el ciclo de desarrollo. Los equipos de gestión de proyectos deben comprender por qué se lleva a cabo este proceso y comprender que el valor proviene de la reducción de las correcciones urgentes y las optimizaciones del rendimiento.
2. A continuación, definir SLA a nivel de componente adición a los el nivel de la aplicación permite la retroalimentación de la etapa anterior y ayuda a los desarrolladores a comprender el impacto de la modificación del código en los componentes individuales que están desarrollando. Esta prueba de rendimiento granular facilita que las partes interesadas aprendan dónde se producen los puntos de acceso.
3. Es importante migrar la mayor parte de su práctica de pruebas de las pruebas centradas en la interfaz de usuario a pruebas automatizadas como API y pruebas de base de datos. Estos tipos de prácticas de prueba, además de ser más fáciles de mantener y escalables, se pueden aprovechar de inmediato en las pruebas de rendimiento, pueden identificar la causa raíz de los problemas de rendimiento y son muy resistentes a los cambios.
4. Por último, las organizaciones deben integrar las pruebas de rendimiento en el proceso de compilación para que las pruebas básicas de rendimiento de las pruebas de humo se ejecuten al registrar el código, y cada noche se ejecute un conjunto completo de pruebas de rendimiento. Para hacer esto, debe considerar el hardware. Las pruebas de rendimiento automatizadas requieren más recursos informáticos que las pruebas funcionales, por lo que los equipos de desarrollo deben estar preparados para eso. Revisar si la infraestructura de desempeño existente se ajusta al enfoque de cambio a la izquierda o requiere modificaciones (es decir, agentes en la nube) también sería una de las consideraciones clave en la transición a la automatización de pruebas de desempeño.

Roles de desarrollador y tester en Shift-Left Performance

Los desarrolladores SON PROPIOS del rendimiento de sus aplicaciones. Los desarrolladores deben crear aplicaciones que estén listas para las pruebas de rendimiento mediante el uso de microservicios, API REST / SOAP y arquitecturas de diseño modular, de modo que las piezas individuales se puedan probar a medida que se desarrollan.

Los evaluadores pueden alinear sus casos de prueba con los flujos de trabajo clave en la aplicación para que puedan aprovecharse en el proceso de prueba de rendimiento. Centrarse en las capas de API de la aplicación hace que sea más resistente al cambio y manejable. Ambos equipos consumen informes que han caído fuera de los SLA para que la aplicación identifique áreas problemáticas en función de la verificación de código reciente para ayudarlos a identificar qué componentes deben optimizarse.

¿Cómo se integran las herramientas para habilitar Shift-Left Performance?

Seleccionar las herramientas adecuadas para un proceso de prueba de rendimiento de cambio a la izquierda es importante, pero no tan importante como usarlas juntas en flujos de trabajo automatizados. Las pruebas de rendimiento en la etapa inicial a menudo ocurren en bolsillos, donde los probadores y desarrolladores inteligentes individuales idean técnicas utilizando una variedad de herramientas de código abierto y disponibles comercialmente, pero esto finalmente se pasa por alto porque no está integrado como parte de todo el proceso automatizado.

En cambio, los evaluadores deberían utilizar herramientas comerciales especializadas que les permitan crear pruebas de rendimiento de forma automatizada. Los desarrolladores pueden utilizar herramientas similares para optimizar sus esfuerzos o para crear scripts de bajo nivel para impulsar la automatización y la carga. Entonces, ¿qué herramientas necesitas?

Las siguientes herramientas simplifican el mantenimiento, se pueden administrar de manera centralizada y proporcionan una interfaz de usuario fácil de usar para comprender los resultados.

• Herramienta de prueba funcional

  Las pruebas funcionales ya deberían ser parte de su estrategia de pruebas continuas. La herramienta que seleccione para la automatización de pruebas funcionales debe centrarse tanto en la capa API de la aplicación (para simplificar la acción de ejecución y mantenimiento del caso de prueba) como en la capa UI (para pruebas de extremo a extremo y de experiencia del usuario). Las herramientas de prueba funcional se utilizan para crear rutas de ejecución de línea de base (reutilización), ya sea en el nivel de la interfaz de usuario o en el nivel de la API. Estas rutas de ejecución coinciden con las historias de los usuarios, por lo que habrá una correlación entre el resultado de la prueba de rendimiento y la historia del usuario afectada.

• Herramienta de prueba de rendimiento

  Específicamente, necesita una herramienta de prueba de rendimiento que pueda consumir los artefactos de prueba funcional y ejecutarlos bajo carga. Estas herramientas deben tener una variedad de parámetros de control de carga, como la cantidad de usuarios virtuales o transacciones a lo largo del tiempo. Estas herramientas deben luego reportar en un tablero centralizado para agregar resultados.

• Herramienta de virtualización de servicios

  Las herramientas de virtualización de servicios abordan los componentes faltantes de las aplicaciones monolíticas en las primeras etapas de las pruebas de rendimiento de cambio a la izquierda. Uno de los principales desafíos a los que se enfrentará en las primeras etapas de las pruebas de rendimiento es la falta de infraestructura de apoyo, mediante esfuerzos de desarrollo paralelos o componentes de terceros. Al establecer la línea de base de esos sistemas dependientes y modelarlos en servicios virtuales, puede crear condiciones de línea de base de aplicaciones similares a la producción y el enfoque láser en el rendimiento de componentes individuales durante su prueba.

• Herramienta de integración continua

  Las pruebas de rendimiento de Shift-left funcionan mejor cuando se trata de un proceso automatizado. Si se implementa la automatización, "pruebas de rendimiento" significa simplemente la revisión / mantenimiento de las pruebas de rendimiento automatizadas, lo que reduce el tiempo para ejecutar las pruebas a largo plazo, ya que el proceso es automatizado y no manual.

  Al alinear su estrategia de prueba de rendimiento con su estrategia de prueba continua e integrarla con herramientas como Jenkins, Bamboo, Microsoft VSTS, etc., puede crear un proceso completamente automatizado. Sus herramientas de CI deberían permitirle ejecutar las pruebas de rendimiento como una función de verificación de código para que las pruebas de rendimiento consistentes puedan ejecutarse todas las noches.

  Además, sus herramientas de CI deben integrarse con su panel de informes y análisis, y publicar automáticamente los resultados para que pueda comprender rápidamente los datos de tendencias.

• Panel de control centralizado para agregar resultados

  Hablando de su panel de informes y análisis ... Un panel centralizado es importante porque permite a los usuarios comprender el impacto incremental de las pruebas de rendimiento de los componentes al mostrar información de tendencias por proyecto, componente, API, etc.

  Su panel de control centralizado debe brindar la capacidad de automatizar las pruebas de rendimiento, definir SLA que conviertan las pruebas de rendimiento en indicadores de aprobación / falla y ver tendencias históricas. Además, el panel de informes debe proporcionar detalles que vinculen las pruebas de rendimiento con sus requisitos iniciales para que la empresa pueda priorizar adecuadamente los problemas que surjan, así como la vista de alto nivel de aprobación / falla y, al mismo tiempo, cada pequeño detalle, para que usted puede determinar las causas de los fallos una vez detectados.

  El enfoque de cambio a la izquierda agrega a los desarrolladores como usuarios del tablero (además de administradores y evaluadores), por lo que el tablero debe tener los detalles de bajo nivel que los desarrolladores buscan para investigar y establecer de manera efectiva las causas de las fallas de SLA o las tendencias históricas.

Resumen

Los consumidores están agotados con constantes parches calientes y actualizaciones de optimización del rendimiento. Tienen hambre de nuevas características y funcionalidades. Dado que las pruebas de rendimiento se realizan tradicionalmente al final del ciclo, inevitablemente afectan los plazos de entrega y, como tal, se miran a través de una lente negativa. Al federar el proceso de pruebas de rendimiento y permitir que los equipos ágiles cambio de prueba a la izquierda con un enfoque iterativo, los problemas se pueden identificar temprano. Esto no solo garantiza que las decisiones tecnológicas que se tomen puedan evaluarse fácilmente para determinar la degradación del rendimiento, sino que, en última instancia, proporciona un producto de mayor rendimiento en general al optimizar cada área individual y el láser se centra en el rendimiento.