Por el equipo de Quality Engineering de MTP International
La pregunta que da título a este artículo tiene una respuesta técnica y una respuesta de negocio. La respuesta técnica la entrega un reporte de JMeter o k6. La respuesta de negocio es la que realmente importa: si tu sistema no puede sostener el volumen de usuarios que tu campaña, tu temporada o tu lanzamiento va a generar, el problema no es de TI, es de ingresos, reputación y continuidad operativa.
Las pruebas de carga existen para separar lo que tu aplicación puede hacer de lo que parece que puede hacer. Esta distinción cuesta cara cuando se descubre en producción.
¿Qué son las pruebas de carga y qué no son?
Una prueba de carga (load test) es un tipo de prueba no funcional que simula un volumen determinado de usuarios o transacciones concurrentes sobre un sistema, con el objetivo de verificar que cumple sus requerimientos de rendimiento bajo condiciones esperadas de operación.
Lo que una prueba de carga no es:
- No es una prueba funcional. No valida que el flujo de pago funcione correctamente; valida que funcione correctamente cuando 5,000 usuarios lo ejecutan al mismo tiempo.
- No es un test de humo. No basta con que el sistema responda; importa en cuánto tiempo responde y con qué tasa de error.
- No es un ejercicio de una sola vez. Un sistema que pasó la prueba de carga hace seis meses puede no pasarla hoy si se añadieron microservicios, se migró la base de datos o cambió el patrón de consumo.
La prueba de carga forma parte de una disciplina más amplia: el Performance Engineering o QE de performance, que abarca el diseño de la estrategia, la ejecución de los distintos tipos de prueba, el análisis de resultados y la retroalimentación al equipo de desarrollo.
Los 5 tipos de prueba de performance que debes conocer
El término “prueba de carga” se usa en la industria de forma laxa para referirse a varias prácticas distintas. Cada una responde una pregunta diferente y expone un tipo de riesgo diferente. Conocer la distinción es relevante porque cada tipo tiene su momento y su propósito dentro de la estrategia de QE.
1. Prueba de carga (load test)
La pregunta que responde: ¿Mi sistema se comporta bien con el volumen de usuarios que espero en condiciones normales?
La prueba de carga valida el comportamiento del sistema bajo el tráfico anticipado. Simula patrones de uso realistas: usuarios que llegan gradualmente, navegación, transacciones, tiempos de espera entre acciones. El objetivo no es romper nada; es confirmar que el sistema cumple sus SLAs y SLOs bajo la carga que el negocio espera.
Un criterio típico: tiempo de respuesta en el percentil 95 por debajo de 500 ms y tasa de error inferior al 1% durante el pico de carga sostenido.
2. Prueba de estrés (stress test)
La pregunta que responde: ¿Cuál es el punto de quiebre de mi sistema y cómo se comporta cuando lo supera?
La prueba de estrés lleva la carga más allá de lo esperado para identificar el límite superior del sistema: en qué momento los tiempos de respuesta se degradan, cuándo empiezan a aparecer errores, qué componente falla primero. Este conocimiento es esencial para planear capacidad y para saber qué tan rápido se puede recuperar el sistema después de un incidente.
3. Prueba de pico (spike test)
La pregunta que responde: ¿Mi sistema sobrevive un incremento masivo y súbito de tráfico?
Las pruebas de pico simulan escenarios donde el volumen de usuarios escala de forma drástica y casi instantánea: el lanzamiento de un producto, un anuncio en televisión abierta, una campaña viral, la apertura de preventas de un evento masivo. A diferencia de la prueba de estrés, aquí el incremento no es gradual: es un salto.
Esta es la prueba que más organizaciones de retail y banca en México deberían ejecutar y pocas ejecutan con antelación suficiente.
4. Prueba de resistencia (soak test o endurance test)
La pregunta que responde: ¿Mi sistema mantiene su rendimiento durante horas o días de operación continua?
Las pruebas de resistencia exponen problemas que no aparecen en sesiones cortas: fugas de memoria (memory leaks), acumulación de conexiones no liberadas, degradación progresiva de la base de datos. Un sistema puede pasar una prueba de carga de 30 minutos sin problemas y fallar silenciosamente después de 8 horas de operación continua.
Para organizaciones que operan sistemas 24/7, como banca digital o plataformas de e-commerce, la prueba de resistencia no es opcional: es la que valida que el sistema puede sostenerse en producción real.
5. Prueba de escalabilidad (scalability test)
La pregunta que responde: ¿Mi sistema puede crecer cuando el negocio lo necesita?
La prueba de escalabilidad evalúa cómo responde el sistema cuando se incrementan los recursos: más instancias, más nodos, más capacidad de base de datos. El objetivo es confirmar que la arquitectura escala de forma lineal o predecible y que no hay cuellos de botella que limiten ese crecimiento.
En entornos cloud, esta prueba también valida que los mecanismos de auto-scaling funcionan en los tiempos que el negocio necesita.
Las métricas que importan en una prueba de performance
Un reporte de performance puede contener decenas de métricas. Las que definen si el sistema está listo para producción son estas:
- Tiempo de respuesta — El tiempo que tarda el sistema en procesar una solicitud. Se mide en percentiles: p50 (mediana), p90, p95 y p99. Los percentiles altos revelan la experiencia de los usuarios más afectados, que suelen ser los más críticos para la retención.
- Throughput — El número de transacciones o solicitudes que el sistema puede procesar por segundo. Define la capacidad real del sistema, no su capacidad declarada.
- Tasa de errores — El porcentaje de solicitudes que terminan en error. Una tasa de error del 2% puede parecer baja hasta que se traduce a miles de transacciones fallidas durante un pico de tráfico.
- Concurrencia — El número de usuarios que interactúan simultáneamente con el sistema. No equivale a usuarios registrados ni a sesiones activas: es la presión real que reciben los componentes del backend en un instante dado.
- Utilización de recursos — CPU, memoria, conexiones de base de datos, threads activos. Los cuellos de botella de performance suelen aparecer aquí antes de que el usuario los sienta en el tiempo de respuesta.
¿Por qué los sistemas fallan en producción aunque pasaron las pruebas funcionales?
Este es uno de los malentendidos más costosos en la industria de desarrollo de software. Las pruebas funcionales verifican que el sistema hace lo que debe hacer. Las pruebas de performance verifican que puede hacerlo bajo las condiciones reales en que operará.
Una aplicación bancaria puede procesar correctamente una transferencia SPEI cuando la ejecuta un tester en un ambiente controlado. El problema aparece cuando 40,000 clientes intentan ejecutar la misma operación en los primeros minutos después de que el banco lanzó una promoción.
Los factores que explican la mayoría de los fallos de performance en producción:
- Arquitecturas que no se probaron bajo carga real. La configuración del pool de conexiones de base de datos, los timeouts entre microservicios, la capacidad del load balancer: todos estos parámetros funcionan correctamente con tráfico bajo y fallan bajo presión.
- Ambientes de prueba que no reflejan producción. Ejecutar una prueba de carga en un ambiente con 20% de la capacidad del productivo entrega resultados que no son extrapolables. El modelo debe calibrarse o el resultado es una falsa seguridad.
- Datos de prueba que no representan el volumen real. Una base de datos con 1,000 registros responde diferente a una con 50 millones. La latencia de las consultas cambia. Los índices se comportan diferente. Los joins escalan de formas no lineales.
- Ausencia de pruebas de terceros. Los sistemas modernos integran pasarelas de pago, servicios de autenticación, APIs de proveedores. El rendimiento de la aplicación depende del rendimiento de cada integración bajo carga, no solo del código propio.
El costo de no hacer pruebas de carga
Los números disponibles sobre el impacto del rendimiento en la experiencia del usuario son contundentes.
Amazon calculó que una desaceleración de apenas un segundo en el tiempo de carga de su página podría costarle USD $1.6 mil millones en ingresos anuales. Walmart encontró que cada mejora de un segundo en el tiempo de carga equivale a un incremento del 2% en conversiones. StickpngStickpng
El 53% de los usuarios en mobile abandona una página si tarda más de tres segundos en cargar. Un retraso de un segundo puede reducir las conversiones hasta un 7%. FireflydigitalmediaRaiola Networks
Estas cifras corresponden a organizaciones con tráfico masivo, pero el principio aplica a cualquier escala: cuando un sistema falla bajo carga, el costo no aparece en el presupuesto de TI, aparece en el resultado del negocio.
En sectores regulados como banca y seguros en México, el riesgo es doble: además del impacto en ingresos y retención, un incidente de disponibilidad puede generar reportes ante la CNBV, comprometer el cumplimiento de SLAs contractuales con empresas o desencadenar auditorías regulatorias.
El mercado global de servicios de pruebas de carga se valoró en USD 2.5 mil millones en 2022 y se proyecta que alcanzará los USD 5.1 mil millones para 2030, con una tasa de crecimiento anual del 10.4%. El crecimiento refleja que las organizaciones están reconociendo que la resiliencia del sistema no es un requisito técnico opcional: es una capacidad de negocio. Verified Market Reports
¿Cuándo hacer una prueba de carga? Los momentos que no admiten improvisar
No existe un único momento correcto para hacer pruebas de performance, pero hay momentos en los que no hacerlas tiene consecuencias predecibles:
Antes de un evento de tráfico conocido. Temporada navideña, Buen Fin, Hot Sale, lanzamiento de campaña masiva, pago de nóminas en banca. Estos eventos son predecibles. El volumen de usuarios es estimable. No llegar a ese evento con una prueba de pico ejecutada y resultados analizados es una decisión que el negocio paga caro.
Antes de un release con cambios de arquitectura o infraestructura. Migración a la nube, cambio de proveedor de base de datos, refactorización de microservicios, incorporación de una nueva pasarela de pago. Cualquier cambio que afecte la ruta crítica de las transacciones de mayor volumen requiere una validación de performance antes del pase a producción.
Cuando el sistema creció pero la arquitectura no. Un sistema que nació para 10,000 usuarios registrados y hoy tiene 500,000 clientes activos probablemente no fue diseñado para el volumen que tiene hoy. Los problemas de performance en estos casos no son bugs: son deuda técnica que se acumula hasta que aparece en producción en el peor momento posible.
Cuando los tiempos de respuesta están empeorando sin causa aparente. La degradación progresiva del rendimiento es una señal. Puede ser una fuga de memoria, un índice de base de datos que creció sin mantenimiento, un servicio externo que cambió su comportamiento. La prueba de resistencia (soak test) es el instrumento diagnóstico para este escenario.
Preguntas frecuentes sobre pruebas de carga
- ¿Cuántos usuarios simultáneos soporta mi aplicación? La respuesta correcta a esta pregunta no es un número fijo: es una combinación de volumen, tipo de operación y criterio de aceptación. Una aplicación puede soportar 50,000 usuarios simultáneos navegando el catálogo de productos y degradarse a 8,000 usuarios si todos ejecutan el proceso de checkout al mismo tiempo. La prueba de carga define la capacidad real por escenario crítico de negocio, no un número genérico.
- ¿Cuál es la diferencia entre una prueba de carga y una prueba de estrés? La prueba de carga (load test) valida el comportamiento del sistema bajo el volumen de usuarios esperado. La prueba de estrés (stress test) lleva la carga más allá del límite esperado para identificar el punto de quiebre y el comportamiento del sistema cuando lo supera. Las dos son complementarias: la primera dice si el sistema está listo para el día normal, la segunda dice qué pasa cuando ocurre lo que no estaba planeado.
- ¿Por qué mi app falló en producción si pasó todas las pruebas funcionales? Las pruebas funcionales verifican que el sistema hace lo correcto. Las pruebas de performance verifican que puede hacerlo bajo la presión de usuarios reales y concurrentes. Los fallos de producción bajo carga suelen ocurrir en la interacción entre componentes, no en la funcionalidad de cada uno por separado: el pool de conexiones de la base de datos, los timeouts entre microservicios, la capacidad del load balancer bajo carga sostenida.
- ¿Con cuánta antelación debo hacer una prueba de carga antes de un evento? El mínimo operativamente razonable es cuatro semanas antes del evento. Ese tiempo permite ejecutar la prueba, analizar resultados, implementar correcciones en el código o la infraestructura, y ejecutar una validación de que las correcciones resolvieron el problema. Organizaciones que operan en banca o retail de alto volumen en México planifican sus pruebas de performance para temporadas críticas con dos a tres meses de antelación.
- ¿Cómo opera la IA de MTP en las pruebas de performance sin comprometer el control regulatorio? Los agentes de IA de MTP intervienen en tres puntos del proceso de performance testing: generación de escenarios de carga basados en patrones de tráfico reales, análisis de resultados para identificar el componente que está generando la degradación, y predicción del punto de quiebre bajo proyecciones de crecimiento. El modelo de adopción en organizaciones bajo regulación CNBV o PCI-DSS opera como IA Controlada: la IA produce el análisis y la recomendación, y un especialista valida cada decisión crítica antes de que llegue al equipo de desarrollo. Esto permite aprovechar la velocidad del análisis automatizado sin comprometer los requisitos de trazabilidad y supervisión que exigen los marcos regulatorios aplicables.
- ¿Qué herramientas usan en MTP para las pruebas de performance? Trabajamos con las herramientas que mejor se integran al stack tecnológico y al pipeline de CI/CD de cada cliente: JMeter, k6, Gatling, NeoLoad, LoadRunner, BlazeMeter y Azure Load Testing, entre otras. La selección de herramienta no define la estrategia: la estrategia se diseña desde Omniatest® y la herramienta se elige según el tipo de prueba, la arquitectura del sistema y los requerimientos de integración con el pipeline del cliente.
¿Tienes un evento de tráfico en el horizonte y no has validado la capacidad de tu sistema?
Agenda una conversación de 30 minutos con un especialista de MTP. Sin agenda de venta, con una perspectiva operativa concreta sobre tu escenario.