¿Hay que probar el rendimiento durante todo el desarrollo o al final del proyecto? ¿Qué enfoque es recomendable elegir? ¿Ágil o en cascada?

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)?

Pruebas de Performance: Concepto y generalidades

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. Recuerda, 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, verificando que el sistema funciona según sea necesario.

Demos un vistazo a lo que implican y luego a las ventajas y desventajas del enfoque ágil y de cascada.

Enfoque en Cascada

En el enfoque en cascada para las pruebas de performance generalmente esperamos hasta el final del desarrollo para comenzar a probar. Los tests de rendimiento 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 ideal 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.

Enfoque Ágil

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

Pros

• Minimiza los riesgos.
• Se obtiene un feedback anticipado y continuo.
• Puedes conocer las mejores prácticas a medida que avanza y, con el tiempo, mejorar continuamente. Cuando comienza con el testing anticipadamente, si haces algo mal, tienes tiempo para detectar tu 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 falsedad que al probar los componentes por separado, el sistema funcionará correctamente. Eso no es necesariamente cierto. Debe probar los componentes individualmente y luego probar cómo funcionan 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 tienes que trabajar. Es importante contar con testers con habilidades técnicas y blandas adecuadas para las pruebas de performance.

También debes tener en cuenta qué herramientas usar al realizar pruebas de carga, como por ejemplo JMeter, BlazeMeter, Gatling, etc. Monitorear tanto en el lado del servidor con herramientas como 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 elabores un plan de ejecución, te recomendamos probar con una línea de base y luego utilizar un enfoque iterativo e incremental.

Entonces, ¿cuál es el enfoque adecuado para el testing de performance? La respuesta es que depende de cuál sea el resultado deseado.

¿Cuándo optar por el Enfoque en Cascada?

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

• Necesitas verificar que tu sistema soporta una determinada carga.
• Tus clientes requieren evidencia de que tu 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 sospechas que se requiere cierto ajuste para un contexto específico donde se ejecutará la aplicación.

¿Cuándo escoger un Enfoque de Testing Á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, agile y en cascada, 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.

Ágil o en cascada: ¿cuál enfoque elegir en el desarrollo?

En Abstracta, muchos de nuestros clientes acuden a nosotros pidiéndonos que adoptemos el enfoque en 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 ejecuta pruebas de performance continuas. Esto les permite tener un entorno de CI, publicando actualizaciones frecuentemente para mejorar la experiencia del usuario sin permitir degradaciones del rendimiento.

¿Cuál ha sido tu experiencia con el enfoque ágil y en cascada? ¡Cuéntanos en los comentarios!

¿No sabes cuál enfoque de testing elegir para tu proyecto? ¿Quieres saber qué tipos de pruebas de rendimiento son idóneos para asegurar una buena experiencia a tus usuarios?

En Abstracta somos expertos en performance testing desde hace más de 14 años, con más de 300 proyectos finalizados con éxito. Contáctanos y conversemos sobre cómo podemos ayudarte a desarrollar e implementar un plan de pruebas de performance desde el inicio del ciclo del desarrollo del software. Así como a mejorar los tiempos de respuesta y de carga de tu sistema, e-commerce o app.

Otros contenidos relacionados