¿Debemos probar el rendimiento durante todo el desarrollo o al final? Enfoque ágil vs. Enfoque en cascada

Imagen tomada de Pixabay

Cuando se tiene en cuenta la performance de los sistemas existentes o los creados desde cero, los equipos deben determinar en qué punto del proceso de desarrollo se beneficiarán más de la ejecución de las pruebas de performance. Hablé sobre este tema en un par de conferencias, incluida la CMG imPACt Conference en La Jolla junto a Sofía Palamarchuk, y pensé ¿por qué no resumir la charla en un post publicación? Entonces, el propósito de este post es responder a la pregunta:

¿Deberíamos comenzar las pruebas de performance al inicio, junto con el desarrollo (adoptando el enfoque ágil), o al final (adoptando el enfoque en cascada)?

¿Qué implican las Pruebas de Performance?

La performance de un computador se caracteriza por la cantidad de trabajo útil realizado por un sistema informático en comparación con el tiempo empleado y los recursos utilizados. Recuerde, la performance no solo se refiere a la velocidad. Por ejemplo, un sistema que es muy rápido y usa el 100% de la CPU no funciona. Por tanto, es importante que comprobemos tanto la experiencia del usuario (el tiempo de respuesta percibido, o la velocidad) como el nivel de estrés de los servidores.

Además, si solamente prestamos atención a los tiempos de respuesta, solo podríamos ver indicios cuando lo que realmente queremos encontrar son las causas subyacentes para identificar esos cuellos de botella y las formas en las que podríamos mejorar.

Entonces, volviendo a la pregunta en cuestión: ¿Deberíamos adoptar el enfoque de cascada o el enfoque ágil , para las pruebas de performance?

Ahora, vale aclarar lo que queremos decir con ambos enfoques dos: El enfoque ágil es cuando comenzamos las pruebas de performance al inicio del proceso de desarrollo y continuamos con este enfoque durante toda la evolución de la aplicación.

Mientras que, el enfoque en cascada es cuando dejamos todas las actividades de pruebas de performance para el final del desarrollo, tales como las pruebas de aceptación, comprobando que el sistema funciona según sea necesario.

Demos un vistazo a lo que implican y luego a las ventajas y desventajas de cada uno.

El Enfoque de Cascada

Imagen de pasja1000 en Pixabay

En este enfoque, generalmente esperamos hasta el final del desarrollo para comenzar a probar. Las pruebas de performance toman la forma de pruebas de aceptación y, si se cumplen los criterios, el sistema está listo para entrar en producción. Esto implica simular el escenario de carga esperado.

Pros

  • Es más fácil planificar y asignar recursos para las pruebas de performance, ya que solo lo hace durante un período de tiempo determinado.
  • Normalmente, intenta utilizar un entorno de prueba lo más similar posible al de producción, lo cual es beneficioso porque es más realista.
  • Permite centrarse en características específicas para probar (como X cantidad de funcionalidades en un contexto específico).

Contras

  • Si bien es genial que estemos probando en un entorno similar al de producción, al mismo tiempo puede ser difícil obtener la infraestructura para un uso exclusivo de las pruebas, es necesario aislar el SUT (System under test, es decir, aquello que se está probando) para tener resultados confiables.
  • El costo de realizar cambios de arquitectura hacia el final del desarrollo (si la prueba muestra que es necesario) es alto.
  • Existe un alto riesgo que conlleva esperar para asegurar el rendimiento al finalizar, porque nunca se sabe cuánto trabajo se tendrá por delante para volver al inicio y solucionar las cosas para alcanzar los objetivos de performance.

El Enfoque Ágil

Foto de Patrick Perkins en Unsplash

El enfoque ágil de las pruebas de performance implica comenzar desde el principio con las pruebas unitarias. Es clave tener un entorno de integración continua, ya que en lugar de simplemente realizar pruebas de performance, llevamos a cabo la ingeniería de performance.

Pros

  • Minimiza los riesgos.
  • Se obtiene una retroalimentación temprana y constante.
  • Conoce las mejores prácticas a medida que avanza y, con el tiempo, mejora continuamente. Cuando comienza con el testing anticipadamente, si hace algo mal, tiene tiempo para detectar su error y evitar cometerlo nuevamente. Es excelente para reducir la probabilidad de propagar malas prácticas por todo el sistema.
  • Facilita la integración continua.

Contras

  • Requiere más esfuerzo de automatización para escribir y mantener scripts.
  • Pueden surgir problemas si se automatiza demasiado poco o demasiado en ciertos niveles. Por ejemplo, es mejor automatizar tantas pruebas de performance unitarias como sea posible, tener algunas en el nivel de API y solo automatizar los casos de prueba más críticos en el nivel de GUI (Interfaz gráfica de usuario).
  • Esto está de acuerdo con la idea de la pirámide de automatización de Michael Cohn, pero se aplica a la performance. Tenga en cuenta que tendrá que reflexionar sobre qué es una prueba de unidad de performance en su caso.
  • A veces, los equipos no reconocen que es una falacia que si prueban los componentes por separado, el sistema funcionará correctamente. Eso no es necesariamente cierto. Debe probar los componentes individualmente y luego probarlos trabajando juntos para lograr los mejores resultados.

Al elegir entre estos dos enfoques, primero es importante hacer un balance de las personas, la tecnología y los procesos con los que tiene que trabajar. Es importante contar con testers con habilidades técnicas y blandas adecuadas para las pruebas de performance. También debe tener en cuenta qué herramientas usar al realizar pruebas de carga (es decir, JMeter, BlazeMeter, Gatling, etc.) y monitorear tanto en el lado del servidor (es decir, New Relic, NMON, perfmon, etc.) como del lado del cliente (con herramientas como Apptim, Page Speed ​​e Yslow). Los procesos incluyen diseño de pruebas, automatización de pruebas, ejecución de pruebas y medición. Cuando elabore un plan de ejecución, le recomendamos que pruebe con una línea de base y luego use un enfoque iterativo e incremental.

Entonces, ¿cuál es el enfoque adecuado? Bueno, depende de cuál sea el resultado deseado.

Cuándo optar por el Enfoque en Cascada

Es posible que desee ejecutar una simulación de carga al final cuando:

  • Necesite verificar que su sistema soporta una determinada carga.
  • Sus clientes requieren evidencia de que su sistema cumple con un cierto estándar de performance (por ejemplo, si su cliente es un banco y quiere asegurarse de que su sistema bancario online puede admitir 100.000 usuarios diarios).
  • Si sospecha que se requiere cierto ajuste para un contexto específico donde se ejecutará la aplicación.

Cuándo optar por el Enfoque Ágil

Es posible que deba optar por este enfoque que implica ingeniería de performance durante todo el desarrollo cuando:

  • Desee reducir los riesgos y los costos.
  • Desee aumentar el conocimiento colectivo del equipo sobre la ingeniería y la supervisión del performance, ya que aprenden sobre este durante todo el proceso.
  • Cuando su objetivo es seguir un esquema de integración continua.

¿Podemos afirmar definitivamente que un enfoque es mejor que el otro en todos los casos? No.

Necesitamos ambos enfoques en diferentes etapas de nuestro ciclo de desarrollo. Debemos comenzar anticipadamente haciendo ingeniería de performance y también debemos simular la carga para las pruebas de aceptación. Y, en realidad, los dos enfoques no son tan diferentes. Ambos requieren el mismo uso de personas, tecnología y procesos, pero varían ligeramente dependiendo de qué tan avanzado esté el desarrollo.

Elegir entre los dos Enfoques en la vida real

En Abstracta, muchos de nuestros clientes acuden a nosotros pidiéndonos que adoptemos el enfoque de cascada, con la intención de ejecutar simulaciones de carga y pruebas de aceptación antes de la puesta en funcionamiento de una nueva versión de su sistema o después de realizar un cambio a su arquitectura, etc. Hicimos esto con una institución financiera que se había fusionado recientemente con otra, y necesitaba asegurarse de que después de haber duplicado el número de cuentas en su sistema de banca online, la performance no se vería afectada.

Otros clientes han tomado la ruta de la ingeniería de performance, como el gigante del e-commerce, Shutterfly, que realiza este tipo de pruebas de forma continua. Esto les permite tener un entorno de integración continua, publicando actualizaciones con frecuencia para mejorar la experiencia del usuario sin permitir degradaciones de la rendimiento. Lea más sobre el esquema de testing de performance continuo de Shutterfly aquí.

Le recomendamos consultar nuestros otros artículos sobre performance o agendar aquí una consultoría gratuita con nuestros expertos, para entender cuál es el momento oportuno para comenzar con las pruebas de performance. 

Por último, cuéntenos en los comentarios cuál es su experiencia con el enfoque ágil y enfoque en cascada,


Otros contenidos relacionados

¿Por qué son necesarias las Pruebas de Performance?

¿Cómo diseñar un Plan de Pruebas de Performance?

3 métricas clave de Pruebas de Performance que todo tester debe conocer