Curiosidades QA — Día 2 de 7 Esta semana publico una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
El deploy más peligroso del mundo
Imagina que haces un deploy. Pero no a un servidor. No a una app móvil. A 2 millones de autos que están en la calle ahora mismo.
Eso es exactamente lo que hace Tesla cada vez que lanza una actualización OTA (Over-The-Air).
Un cambio en el software del piloto automático. Una mejora en la gestión de batería. Un ajuste en el sistema de frenado. Todo llega al auto mientras está estacionado en el garaje de alguien — o peor, mientras está cargando en una estación.
Y si algo sale mal, no puedes hacer rollback. No puedes decirle a 2 millones de personas “oye, ven al taller a que te arreglemos el auto”.
¿Qué hace especial a un OTA automotriz?
En software web, si tu deploy falla:
- Haces rollback en 30 segundos
- El usuario recarga la página y listo
- Nadie se muere
En un auto, si tu deploy falla:
- Los frenos podrían no responder como se espera
- El sistema de navegación podría congelarse en plena autopista
- La batería podría drenar más rápido de lo previsto
- No hay “ctrl+z” — el auto ya tiene el software nuevo
Tesla no es la única. BMW, Mercedes, Volvo y Ford también hacen actualizaciones OTA. Pero Tesla es la que más depende de ellas — su modelo de negocio es que el auto mejora con el tiempo a través de software.
Cómo testea Tesla (lo que se sabe)
Tesla no publica sus procesos internos de QA, pero por patentes, reportes de ingenieros y documentación regulatoria, sabemos que:
1. Shadow mode
Antes de activar una función nueva, Tesla la ejecuta “en sombra” en miles de autos. El sistema nuevo corre en paralelo con el actual, pero no controla nada. Solo observa y registra qué habría hecho.
Si el sistema nuevo habría frenado cuando no debía, o no habría frenado cuando sí debía — eso se detecta sin poner a nadie en riesgo.
2. Rollout progresivo
No actualizan 2 millones de autos al mismo tiempo. Empiezan con un porcentaje pequeño — empleados, beta testers, regiones específicas. Si no hay anomalías en las primeras horas, amplían.
Es el mismo concepto de canary deployment que usamos en software web. Pero con autos.
3. Telemetría en tiempo real
Cada auto Tesla reporta datos de comportamiento constantemente. Si después de una actualización el patrón de frenado cambia de forma inesperada en un grupo de vehículos, hay alarmas automáticas.
En 2022, Tesla tuvo que hacer un recall de casi 54,000 vehículos porque una actualización del Full Self-Driving permitía que el auto hiciera “rolling stops” en señales de alto. El fix llegó… como otra actualización OTA.
El problema que nadie ve: la combinación
Lo más difícil no es testear el software nuevo. Es testear el software nuevo en combinación con:
- Diferentes versiones de hardware (Model 3 de 2019 vs Model Y de 2024)
- Diferentes condiciones climáticas (no es lo mismo la batería en Noruega que en Arizona)
- Diferentes versiones de software previo (no todos los autos tenían el mismo punto de partida)
- Diferentes hábitos de conducción
Esa matriz de combinaciones es astronómica. Y cada combinación tiene que funcionar. Porque cuando falla, no falla un endpoint — falla un freno.
La paradoja del éxito silencioso
Aquí está lo curioso: cuando Tesla hace un buen deploy, nadie se entera. El auto simplemente funciona mejor al día siguiente. Nadie felicita al equipo de QA.
Pero cuando algo falla — un recall, un accidente, una noticia — todo el mundo sabe quién fue.
Es la misma paradoja que vivimos todos los QA: nuestro mejor trabajo es invisible.
La reflexión
La próxima vez que sientas presión por un deploy, recuerda: hay un equipo en Tesla que despliega software a 2 millones de máquinas de 2 toneladas que van a 120 km/h. Y no pueden hacer rollback.
Tu deploy a producción, con rollback disponible, con feature flags, con canary — de repente no parece tan estresante.
Pero la lección de Tesla aplica a cualquier escala: las mejores estrategias de testing asumen que algo va a fallar. Shadow mode, rollout progresivo, telemetría, alarmas automáticas — todo está diseñado para detectar el problema antes de que sea irreversible.
Eso no es paranoia. Es ingeniería.
Mañana: ¿Por qué Netflix destruye sus propios servidores a propósito? → Día 3