Entrando en tema
La charla de Rodrigo Campos, «Falló el Pago? Ya es muy tarde. Hablemos de Continuous Performance (Shift Left)», subraya la necesidad crítica de integrar las pruebas de rendimiento desde las fases iniciales del ciclo de desarrollo de software, un enfoque conocido como Shift Left. Se argumenta que postergar estas pruebas hasta el final no solo es arriesgado, sino que representa un costo exponencialmente mayor en términos de recursos, tiempo y reputación. A través de un caso de estudio sobre un lanzamiento fallido, se demuestra cómo la presión por cumplir plazos funcionales lleva a omitir pruebas no funcionales, resultando en un desastre técnico y comercial. La conclusión principal es que las pruebas de rendimiento tempranas y continuas no son un gasto, sino «un seguro contra el desastre». El camino hacia la madurez en esta área implica un cambio de mentalidad, donde la calidad se construye colaborativamente desde el inicio, se integra la observabilidad como pilar fundamental y se adoptan herramientas y metodologías para validar el rendimiento de manera constante y automatizada en cada etapa del desarrollo. La charla se dió durante la 9na edición del Testing Day Chile.
El costo de un lanzamiento fallido: El caso «Softify»
Para ilustrar las catastróficas consecuencias de descuidar el rendimiento, se presentó un caso de estudio sobre «Softify», una startup que preparaba el lanzamiento de una nueva aplicación de pagos instantáneos.
• El escenario: La startup había invertido significativamente en una campaña de marketing masiva (televisión, radio, correos) que ya estaba pagada y agendada. Los inversores habían marcado la fecha de lanzamiento como un hito crucial, generando una enorme presión sobre el equipo técnico.
• La advertencia ignorada: Mateo, el líder del equipo de QA, insistió durante semanas en la necesidad de realizar pruebas de rendimiento. Sin embargo, la respuesta constante de la dirección (CTO) fue: «Mateo, eso lo vamos a ver al final. Ahora hay que terminar las funcionalidades». Esta decisión priorizó la velocidad de entrega de características sobre la estabilidad del sistema.
• La prueba tardía y desastrosa: El equipo de QA, no especialista en performance, logró obtener una ventana de solo dos días antes del lanzamiento para realizar algunas pruebas. Los resultados fueron alarmantes:
◦ Se detectaron hasta seis consultas a la base de datos por cada transacción, una sobrecarga calificada como «una locura».
◦ Con 300 usuarios concurrentes, la API comenzó a responder en 8 segundos, un tiempo inaceptable considerando que el estándar de la industria es inferior a 3 segundos (idealmente 1 segundo, según Google).
◦ Al llegar a los 500 usuarios concurrentes, la aplicación colapsó por completo.
• Las consecuencias: El equipo técnico trabajó ininterrumpidamente durante 48 horas, pero cada cambio requería nuevas y extensas pruebas. El lanzamiento tuvo que ser retrasado, frustrando al CEO y agotando a los equipos de desarrollo y QA. El incidente generó una mezcla de alivio por haber detectado el problema a tiempo y rabia por haber sido una crisis previsible y evitable.
Lecciones aprendidas del incidente
El fracaso del lanzamiento forzó a la empresa a reestructurar su enfoque hacia la calidad y el rendimiento, adoptando las siguientes prácticas:
1. Pruebas de carga en cada sprint: Se implementaron pruebas de rendimiento ligeras y constantes en cada ciclo de desarrollo.
2. Revisión continua de la arquitectura: Se reconoció que la arquitectura del sistema debe evolucionar junto con el producto para soportar nuevas funcionalidades y mayor carga.
3. Ejecución automática de pruebas: Las pruebas de rendimiento se integraron en el pipeline para ejecutarse automáticamente con cada despliegue, funcionando como una validación de línea base (baseline).
4. Formación del equipo de QA: Se invirtió en la capacitación del equipo para desarrollar las habilidades necesarias en pruebas de rendimiento.
Shift Left: El arte de anticiparse a los problemas
El concepto de Shift Left es el pilar central de la charla, presentándose como la estrategia fundamental para evitar crisis como la de «Softify». Consiste en mover las actividades de testing, especialmente las de rendimiento, hacia la izquierda en el ciclo de vida del desarrollo, es decir, a fases más tempranas.
Ventajas clave del enfoque Shift Left:
• Reducción de costos: Resolver problemas de rendimiento en etapas tempranas es significativamente más económico que hacerlo en producción o justo antes del lanzamiento.
• Prevención sobre reacción: Permite a los equipos de QA y Desarrollo trabajar en conjunto para prevenir problemas, en lugar de reaccionar a crisis.
• Retroalimentación rápida: La inclusión de pruebas ligeras en cada sprint y despliegue valida constantemente el rendimiento del servicio, API o aplicación, permitiendo detectar regresiones de rendimiento de inmediato.
• Evitar sorpresas en producción: Al probar en ambientes lo más cercanos posible a producción (UAT, Staging) de forma continua, se minimiza el riesgo de fallos inesperados tras el lanzamiento.
Guía práctica: ¿Cómo empezar hoy?
Para pasar de la teoría a la práctica, se propone un modelo de implementación basado en los siguientes pasos:
| Etapa | Descripción |
| 1. Definir objetivos | Establecer métricas claras y medibles para el éxito, como tiempos de respuesta (ej. percentil 95), throughput (transacciones por segundo) y tasa de errores aceptable. Sin objetivos, las pruebas carecen de dirección. |
| 2. Definir procesos y responsables | Identificar quiénes participarán en el análisis: QA, Dev, Operaciones, Arquitectos, SRE. El experto en performance no conoce todo; su rol es facilitar una visión holística con el conocimiento de los especialistas de cada área. |
| 3. Integrar pruebas ligeras en el Pipeline | Incluir escenarios básicos (smoke tests, baseline) en cada build. Estas pruebas rápidas ayudan a monitorear la evolución de las métricas de rendimiento con cada cambio en el código. |
| 4. Monitorear en tiempo real | La observabilidad es fundamental. Utilizar herramientas como Datadog, Prometheus o Grafana para ver en profundidad el comportamiento del sistema durante las pruebas, yendo más allá de los resultados superficiales de la API. |
| 5. Iterar y escalar | El proceso no termina. Las pruebas deben repetirse y adaptarse continuamente, mejorando tanto el sistema como las propias pruebas. La calidad, incluida la del rendimiento, es una responsabilidad de todo el equipo. |
El futuro: Observabilidad, Mejora Continua e IA
La charla concluye con una visión sobre la evolución del rol del ingeniero de performance y las tendencias que definirán el futuro de la disciplina.
• Observabilidad como fundamento: Ejecutar pruebas de rendimiento sin un sistema de observabilidad es cubrir solo el 50% del problema. Mientras las pruebas miden el «qué» (tiempos, errores), la observabilidad permite entender el «porqué» (causa raíz del problema).
• Cambio de mentalidad hacia la Mejora Continua: El rol del performance engineer moderno no es solo medir, sino mejorar. Esto implica identificar cuellos de botella, probar hipótesis (ej. «ingeniería del caos» para validar la resiliencia), y utilizar datos para validar la arquitectura.
• La IA como aliado: La Inteligencia Artificial no reemplazará al ingeniero de performance, sino que potenciará sus capacidades, ayudando a analizar grandes volúmenes de datos, predecir problemas y optimizar las pruebas.
Finalmente, se enfatiza que el performance no se prueba al final; se construye desde el inicio.
inicio de la charla en el timestamps: 5:15:00
