Por qué probar en producción dejó de ser herejía y se volvió estrategia.
Hay una conversación que se repite, casi palabra por palabra, en los pasillos de empresas de tecnología. Sucede después de un incidente en producción —uno de esos que dejan a un equipo entero en modo guerra durante un fin de semana—.
Cuando finalmente se restablece el servicio y se hace la retrospectiva, alguien pregunta: “¿Cómo no detectamos esto en QA?”. Y la respuesta, casi siempre, es la misma: “Porque en QA no podíamos reproducir las condiciones reales.” Sigue un silencio incómodo, una promesa de mejorar los ambientes, y la conversación termina.
Lo que casi nunca se dice en voz alta es la verdad incómoda: ningún ambiente preproductivo, por bien construido que esté, es producción. Y esa diferencia —ese último kilómetro— es donde viven los defectos más costosos.
Durante mucho tiempo, la industria del testing trató ese último kilómetro como tierra prohibida. Probar en producción se asociaba con irresponsabilidad, con vaqueros que despliegan los viernes y con titulares de prensa sobre filtraciones de datos. Y para reforzar la frontera, se instaló una idea seductora pero tramposa: que el análisis de riesgos —usado correctamente— justificaba mantenerse fuera de producción a toda costa.
Lo cierto es lo opuesto. El análisis de riesgos bien hecho no concluye “no toques producción”; concluye “toca producción de esta manera específica, con estos controles, sobre estos componentes, midiendo estas señales”. Confundir prudencia con parálisis ha costado miles de millones en defectos descubiertos tarde.
Conviene partir de una distinción simple. Cuando hablamos de testing en producción no nos referimos a ejecutar el plan de pruebas funcional en el ambiente vivo, ni a improvisar exploración manual sobre datos reales de clientes. Nos referimos a un conjunto de técnicas diseñadas específicamente para validar comportamiento en condiciones reales con riesgo controlado. Son técnicas que requieren disciplina, herramientas, observabilidad y, sobre todo, una mentalidad que entiende que la calidad es un proceso continuo, no un punto de control único antes del despliegue.
- Técnicas de testing en producción en la industria actual
Las prácticas más consolidadas en la industria de software actual, resuelven riesgos distintos y se aplican en momentos distintos del ciclo de despliegue.
- Canary release
Esta liberación controlada expone primero la nueva versión a un pequeño porcentaje de usuarios reales (típicamente entre 1% y 5%) mientras el resto sigue usando la versión estable.
Cómo se hace: se utilizan plataformas como Kubernetes, service meshes (Istio, Linkerd) u orquestadores cloud para dirigir tráfico con precisión. Se monitorean en tiempo real métricas técnicas (latencia, tasa de error, consumo de recursos) y se establece un rollback automático si los umbrales se exceden.
Si el “canario” canta tranquilo, el porcentaje de tráfico se incrementa progresivamente hasta el 100%. Netflix popularizó esta práctica con su plataforma Kayenta, que automatiza la comparación estadística entre la versión nueva y la baseline.
- Blue-green deployment
Es la coexistencia de dos ambientes productivos idénticos, uno activo (azul) y uno en espera (verde), con conmutación inmediata entre ellos.
Cómo se hace: se despliega la nueva versión en el ambiente verde, se valida con humo y pruebas automáticas, y cuando todo está confirmado, se conmuta el balanceador para dirigir el tráfico al verde. Si aparece un problema, basta con devolver el switch al azul y el regreso es instantáneo.
Es la red de seguridad por excelencia para sistemas donde un rollback lento sería catastrófico.
- Shadow testing (duplicación de tráfico)
Esta técnica silenciosa redirige una copia del tráfico real a la nueva versión del servicio, que procesa todo pero sin devolver respuestas a los usuarios.
Cómo se hace: mediante proxies o herramientas de mirroring (GoReplay, Envoy, AWS VPC Traffic Mirroring), se duplica el tráfico productivo hacia un ambiente paralelo. La nueva versión ejecuta cálculos, llamadas a base de datos e integraciones, pero sus respuestas se descartan.
Esto permite validar refactorizaciones masivas, migraciones de motor de base de datos o nuevos modelos de IA sin que un solo cliente se convierta en un conejillo de indias.
Para sistemas críticos —core bancario, salud, energía— es a veces la única forma honesta de probar a escala real.
- Dark launches y feature flags
En estas los despliegues de código a producción se mantienen ocultos detrás de banderas (flags) que controlan quién lo ve y cuándo.
Cómo se hace: con plataformas como LaunchDarkly, Unleash o Flagsmith, la funcionalidad existe en el código pero permanece desactivada. Se enciende progresivamente: primero a empleados internos, luego a un grupo piloto, luego a una región, finalmente a todos.
Si algo sale mal, se apaga la bandera y listo, sin necesidad de redesplegar. Permite separar el momento del despliegue del momento del lanzamiento.
- A/B testing
Es la comparación simultánea de dos versiones para medir cuál genera mejores resultados de negocio (conversión, retención, satisfacción) y no solo técnicos.
Cómo se hace: se segmentan los usuarios en grupos estísticamente comparables (A y B), cada uno recibe una versión y se mide el comportamiento durante el tiempo necesario para alcanzar significancia estadística. Aquí el testing se hermana con producto y growth, ampliando el rol del QA hacia decisiones estratégicas.
- Chaos engineering
La práctica de provocar fallas controladas en producción para verificar que los mecanismos de resiliencia funcionan de verdad.
Cómo se hace: con herramientas como Chaos Monkey, Gremlin o Litmus se inyectan fallas —terminar instancias, degradar la red, saturar CPU, simular caída de dependencias— sobre componentes seleccionados. Se observa si los reintentos, circuit breakers, autoscaling y planes de contingencia responden como se diseñaron.
Es la diferencia entre tener un extintor colgado en la pared y haberlo usado realmente alguna vez.
- Synthetic monitoring y smoke testing en producción
La ejecución continua de transacciones automatizadas sobre rutas críticas del producto (login, búsqueda, pago, checkout) para detectar degradaciones antes que un usuario real.
Cómo se hace: con herramientas como Datadog Synthetics, New Relic Synthetic, Checkly o scripts propios programados, se simulan flujos completos cada pocos minutos desde múltiples geografías. Los resultados alimentan dashboards y alertas que disparan respuesta antes de que el incidente escale.
- ¿Cuándo aplicarlo y cuándo no? Una mirada honesta
Es justo preguntarse: ¿cuándo no aplicar testing en producción? Hay contextos donde la cautela debe pesar más que el entusiasmo.
Aplicar TiP – Testing in Production – sin las bases es peor que no aplicarlo. La salida no es elegir entre extremos, sino reconocer en qué punto de madurez está la organización y tu equipo, y construir las capacidades necesarias antes de avanzar.
La siguiente tabla resume las condiciones que facilitan o dificultan la adopción del testing en producción, considerando tanto características del negocio como del equipo de TI:
| Características | Que facilitan | Que dificultan |
|---|---|---|
| Madurez de observabilidad | Logs centralizados, métricas en tiempo real, trazas distribuidas y dashboards accionables. | Sin trazabilidad ni alertas; los incidentes se descubren por quejas de usuarios. |
| Pipeline de CI/CD | Despliegues automatizados, rollback en minutos y feature flags ya en uso. | Despliegues manuales, ventanas largas de mantenimiento y rollback complejo. |
| Sensibilidad regulatoria de los datos | Datos pseudonimizados, segmentación por roles y trazabilidad de auditoría disponible. | Datos personales o financieros sin anonimizar, sin controles de acceso granulares. |
| Arquitectura del producto | Microservicios, contenedores o serverless con desacoplamiento real entre componentes. | Monolitos altamente acoplados donde un cambio impacta a todo el sistema. |
| Cultura del equipo | Colaboración entre Dev, QA y SRE; mentalidad de mejora continua y postmortems sin culpa. | Silos rígidos, miedo al error y aversión a experimentar; cada incidente busca culpables. |
| Tolerancia al impacto de marca | Producto con base de usuarios diversa, segmentable y con margen para experimentación. | Producto crítico para reputación o seguridad pública donde un fallo público es existencial. |
| Cumplimiento normativo | Marcos de control adaptables (SOC2, ISO 27001) con procedimientos de cambio definidos. | Sectores con regulación rígida sin flexibilidad para experimentos en ambiente vivo. |
| Capacidad de segmentación de tráfico | Service mesh, balanceadores y feature flags que permiten dirigir tráfico con precisión. | Arquitectura sin capacidad de enrutamiento granular; todo o nada. |
Leída en contexto, la tabla deja una conclusión clara: el testing en producción no es una decisión binaria, sino el resultado de una evolución. Una organización que hoy se encuentra en la columna derecha en varias filas no debe descartar TiP, sino diseñar una hoja de ruta para moverse hacia la izquierda en el orden adecuado: primero observabilidad y CI/CD, después segmentación y feature flags, y finalmente técnicas más avanzadas como shadow testing o chaos engineering.
- El acelerador: la inteligencia artificial
La irrupción de la inteligencia artificial está cambiando el cálculo riesgo-beneficio de manera contundente. La IA permite hoy lo que hace cinco años era ciencia ficción: detección automática de anomalías sutiles en métricas de producción, generación de carga sintética realista, análisis comparativo entre versiones canary y baseline en segundos, predicción de qué cambios tienen mayor probabilidad de causar incidentes, y exploración automatizada de comportamientos inesperados. Esto no es marketing: son capacidades reales que están bajando la barrera de entrada al testing en producción y, a la vez, expandiendo enormemente la cobertura efectiva del testing.
- La oportunidad para los profesionales de QA
Para los líderes y profesionales de QA, esto abre una ventana profesional que vale la pena tomar en serio. El tester que solo ejecuta casos manuales en ambientes controlados está caminando hacia la obsolescencia.
En cambio, el tester que entiende observabilidad, define SLOs, diseña experimentos de canary y A/B, interpreta dashboards, colabora con SREs y desarrolladores en producción, y aprovecha IA para amplificar cobertura, se convierte en un actor estratégico del producto.
Es un cambio de identidad profesional: del “validador de cumplimiento” al “ingeniero de calidad continua”. Y ese cambio, lejos de ser amenazante, es liberador.
- Una invitación final
El testing en producción no es para los temerarios; es para los disciplinados. No reemplaza las pruebas tempranas; las complementa cerrando el ciclo en el lugar donde el software realmente vive.
Y en una era donde la velocidad de despliegue se mide en minutos y las arquitecturas se vuelven más complejas cada trimestre, ignorarlo no es prudencia: es renunciar a una porción enorme del valor que QA puede aportar al negocio. La pregunta que las áreas de tecnología deberían estar haciéndose ya no es si probar en producción, sino ¿qué tan listos están para hacerlo bien?
Artículo elaborado por Lilia Yarley Estrada Díaz – Líder CoE con asistencia de herramientas de inteligencia artificial generativa.
El enfoque editorial, los criterios técnicos y la responsabilidad del contenido pertenecen a Softesting.
