Pesadilla antes de Navidad

No te preocupes, esta no es otra entrada más en el blog sobre el Black Friday. Yo también estoy saturado de tanto escuchar hablar del Viernes Negro (¡hablemos español!), Cyber Monday y qué se yo. Lo peor de todo es que esta es una moda que ya va camino de tradición, y por lo menos en España no tiene mucho sentido. Pero tú no lees este blog para escuchar mis quejas sobre los extranjerismos y la adopción de tradiciones que ni nos van ni nos vienen, lo haces porque te aporto la visión tecnológica y de negocio relacionada con el mundo del testing. Y me guste o no, el Black Friday es una fecha clave en el calendario.

¿Acaso estas empresas van a esperar a la pesadilla de compras antes de navidad para volver a fallar a sus clientes?

Una gran parte del comercio online cierra el 50% de las ventas anuales en la semana del Black Friday, y por eso los responsables de negocio, marketing y TI tienen está fecha marcada casi a fuego en el calendario. Pero… ¿y los responsables de quality assurance? ¿es igual de importante para ellos una fecha tan significativa en el calendario de otros?

El rendimiento de los sistemas que hace años se daba por supuesto, ya no existe, especialmente porque la arquitectura tecnológica es radicalmente distinta

Ya sabemos que, gracias a las pruebas de software, podemos proteger el negocio asegurando el correcto funcionamiento de las webs donde se genera la venta. De esta forma, cada Black Friday las empresas que tienen procesos de QA establecidos no tienen que vivir tremendas pérdidas y quebraderos de cabeza, cuando sus webs dejen de funcionar durante horas, con lo que ello conlleva para las conversiones y ventas de productos, además de deteriorar el prestigio de una marca con algo tan básico como es el correcto funcionamiento de una web. Un año más te pregunto… ¿van a pasar nuestras recomendaciones desapercibidas una vez más? ¿acaso estas empresas que prefieren no escucharnos van a esperar a la pesadilla antes de navidad para volver a fallar a sus clientes?

De una forma u otra el rendimiento de los sistemas más pronto o más tarde afecta a todas las organizaciones

Puedes pensar que este artículo no es para ti porque tu negocio no tiene nada que ver con las ventas por Internet, pero ¡no dejes de leer aún! Porque tarde o temprano el rendimiento de los sistemas afectará a todas las organizaciones, incluida la tuya. Obviamente, la causalidad en el ejemplo de las ventas online es bastante clara; si mi sitio está caído va lento, mis clientes no pueden comprar, o la experiencia del usuario es tan mala que se van a la competencia. En resumen, pierdo dinero. En otras industrias, el vínculo entre el rendimiento deficiente del sistema y el impacto en los resultados de la empresa puede no ser tan claro.

Lo que intento transmitirte es que el rendimiento de los sistemas que hace años se daba por supuesto, ya no existe, especialmente porque la arquitectura tecnológica es radicalmente distinta.

Vamos a suponer que tu empresa es uno de esos 240.000 clientes que tiene SAP en el mundo. No tienes nada que ver con las compras por internet, sin embargo, a medida que tu organización crece, tu sistema SAP va más y más lento; la productividad de tus empleados se ve impactada (pérdidas económicas), o el proceso de consolidación de SAP BPC es tan complejo que detiene tus sistemas durante horas (pérdidas económicas...).

Estos son solo algunos ejemplos; te podría dar muchos más en entornos que se presuponen “rápidos” por el simple hecho de ser SaaS, como es Salesforce, y donde cada día más clientes nos piden ayuda para optimizarlo.

La clásica solución de meter más hierro en el CPD (o mejor dicho, más euros en AWS o Azure), tampoco es la solución, por costes y porque muchas veces simplemente no funciona. La complejidad del software y el aumento en el volumen de usuarios que interactúan mediante diferentes dispositivos hace que las pruebas de rendimiento y la monitorización de sistemas sea obligatoria, y se realice desde el principio (shift-left, otro palabro sin traducción).

Cliente: “Creo que nos la vamos a pegar en Black Friday, mi cabeza corre peligro. ¿Por dónde empezamos?”

Esta es una frase que solemos escuchar cada año por estas fechas, de una empresa que como muchas otras solo buscan presupuesto cuando le ven las orejas al lobo. Como decía antes, si quieres que Pesadilla antes de navidad solo sea una gran película, y no el presagio de la próxima caída de tu sistema, sigue los siguientes consejos:

1. No lo dejes para el final -Shift Left no es solo empezar a hacer pruebas funcionales y automatización antes en el ciclo de vida, también es pensar en el rendimiento desde el día 0. Tradicionalmente las pruebas de rendimiento se hacían casi al final del desarrollo, ya que su enfoque estaba centrado en los procesos de negocio de inicio a fin. No obstante, con la adopción de estrategias de Continuous Development (CD), Continuous Integration (CI) o Continuous Deployment (CD) es posible integrar las pruebas de rendimiento incluso cada vez que hacemos una build. Por supuesto, necesitas una estrategia de pruebas de rendimiento (y nosotros somos expertos en este punto), de lo contrario no tiene sentido simplemente lanzar pruebas de forma constante. Piensa en evaluar cambios en la tendencia de las gráficas que obtienes, en lugar de mirar al rendimiento del sistema a nivel global. Y no te compliques con miles de usuarios, muchas veces es suficiente con generar una carga mínima y evaluar los cambios entre cada una de las releases / builds / commits...
2. Pruebas por componentes -Tradicionalmente la industria se ha centrado en posicionar herramientas que "graban" lo que el usuario real hace, para luego reproducirlo simulando cientos o miles de conexiones y generar la carga. Ese paradigma de trabajo ya no es necesario. Ahora es posible trabajar directamente contra los componentes, ya sea a nivel webservices o a nivel base de datos (por poner dos ejemplos). Mi recomendación es que pruebes a nivel unitario, no buscando generar carga, sino buscando generar suficiente actividad para identificar tendencias, sobre todo cuando comparas datos entre releases.
3. Simula escenarios reales -No debes olvidarte de que el objetivo de las pruebas de rendimiento es anticiparte a lo que va a pasar en producción, para detectar posibles problemas antes que los usuarios reales lo hagan. Tu plan de pruebas debe contener el detalle de lo que esperas en producción. Antes del gran día (ya sea Black Friday, el cierre contable mensual, o el lanzamiento de una campaña...) crea escenarios de pruebas que simulen estas condiciones y no olvides que no aporta valor generar carga para simplemente "tirar" el sistema, eso lo sabemos hacer todos, pero no son pruebas de rendimiento.
4. Piensa en tus dependencias -Con los entornos heterogéneos, cada vez es más común depender de terceros (ya sean otros departamentos u otras empresas como por ejemplo las pasarelas de pago). Asegúrate que conoces sus planes de pruebas para verificar que cumplen con tus estimaciones; y si no es posible tener está información, piensa en la virtualización de servicios. Esta es una opción excelente, no solo cuando no puedes probar el rendimiento de una plataforma externa, sino también cuando el desarrollo de alguna de tus dependencias va a otro ritmo (por ejemplo, cuando aún no han terminado y tú ya quieres hacer pruebas).
5. Monitoriza en producción -No olvides que el ciclo de vida de una aplicación tiene la palabra ciclo por una razón, es iterativo. La información que obtienes en producción debe servir para planificar mejores pruebas de rendimiento. Es común que muchas de las herramientas usadas para monitorizar en producción de forma sintética también soporten los scripts que has usado durante las pruebas de rendimiento.

Si sigues estos 5 consejos, ya tienes gran parte del camino andado para asegurar que tu plataforma tiene el rendimiento que tus usuarios esperan. Como decía al principio de esta entrada en el blog, si tus sistemas han sufrido durante el Black Friday, no esperes a tener una pesadilla antes de navidad con las rebajas, y llama a los expertos.