Curiosidades QA — Día 7 de 7 Esta semana publiqué una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
Donde los bugs matan
Desarrollar software para un avión comercial cuesta entre 10 y 30 veces más que desarrollar software comercial normal. Por cada línea de código productivo, el proyecto produce entre 50 y 100 páginas de documentación de testing.
No es burocracia. Es supervivencia.
En aviación, un bug no te cuesta un ticket de soporte. Te puede costar cientos de vidas. Y la industria lleva décadas perfeccionando prácticas de QA que el software comercial apenas está descubriendo.
La pregunta que lo cambia todo
En software comercial, la pregunta por defecto es: “¿funciona?”
En aviación, la pregunta por defecto es: “¿qué pasa si falla?”
Esa diferencia de marco mental cambia todo. No es paranoia — es ingeniería. Y es lo que separa software que se cae los viernes de software que no se puede caer nunca.
Mira cómo estructuran el problema:
DAL-A (Catastrófico): una falla puede causar la pérdida del avión. Para este nivel, los requisitos de testing son tan estrictos que un pequeño bug puede retrasar un avión meses.
DAL-B (Peligroso): una falla puede causar daños serios o pérdida de funciones críticas.
DAL-C (Mayor): una falla puede reducir significativamente la seguridad.
DAL-D (Menor): una falla tiene impacto mínimo.
DAL-E (Sin efecto): una falla no afecta la seguridad del avión.
Cada nivel tiene requisitos diferentes de cobertura de testing. No todo se trata igual porque no todo tiene el mismo impacto.
3 prácticas que ya aplicas (sin saberlo)
Lo curioso es que algunas técnicas que la aviación perfeccionó en los 70s y 80s son exactamente las que el software comercial está redescubriendo ahora:
1. Modified Condition/Decision Coverage (MC/DC)
Suena complicado. Es simple: si tu código tiene una decisión compleja con varias condiciones, tienes que probar que cada condición puede cambiar el resultado de forma independiente.
Si tu código dice if (A && B && C), no basta con probar que pasa y que no pasa. Tienes que probar que A puede cambiar el resultado, B puede cambiar el resultado, y C puede cambiar el resultado.
En software comercial llamamos a esto “testing basado en decisiones” o “cobertura de condiciones”. En aviación, es obligatorio desde 1992.
2. Requirements-based testing con trazabilidad completa
Cada caso de prueba en aviación está trazado a un requerimiento específico. Cada requerimiento está trazado a una función del sistema. Cada función está trazada a una especificación regulatoria.
Si alguien pregunta “¿por qué tenemos este test?”, la respuesta no es “porque sí” — es un árbol completo hasta la raíz.
En software comercial a veces llamamos a esto “matriz de trazabilidad”. La mayoría de equipos la ignoran. La aviación la hace desde los 80.
3. Independencia entre desarrollo y testing
En aviación, quien testea el código NO puede ser el mismo que lo escribió. Ni alguien del mismo equipo. La independencia está reglamentada.
Esto evita sesgos cognitivos: el desarrollador que escribió el código tiende a probarlo como él cree que funciona, no como podría fallar.
En software comercial, muchas empresas mezclan dev + QA como si fuera lo mismo. La aviación demostró hace décadas por qué eso es un problema.
Dato curioso: El 737 MAX tenía una función llamada MCAS que podía forzar el avión hacia abajo. La documentación de testing original cubría el caso “si la función se activa correctamente”. No cubría el caso “si la función se activa incorrectamente basándose en datos defectuosos de un solo sensor”. Ese hueco en el testing costó 346 vidas. Desde entonces, el estándar cambió para exigir testing de fallas en sensores redundantes.
Lo que puedes aplicar mañana
No necesitas certificarte en DO-178C para sacar valor de esto. Hay 3 prácticas concretas que cualquier QA puede aplicar:
Pregunta “¿qué pasa si falla?” antes de probar “¿funciona?”
En cada flujo, antes de escribir el primer caso positivo, lista las formas en que puede fallar. Un test que solo cubre el happy path es un test incompleto.
Categoriza tus bugs por impacto real, no por percepción
No todos los bugs son iguales. Un bug en el botón de “compartir” y un bug en el flujo de pago no deberían tratarse igual, aunque ambos se vean como “bug media” en Jira. La industria aérea lo tiene claro desde hace décadas.
Agrega trazabilidad a tus casos de prueba
No tiene que ser un sistema complejo. Solo asegurate de que cada caso de prueba tenga un link al requerimiento que está validando. Cuando el requerimiento cambie, sabrás exactamente qué tests actualizar. Eso es oro.
Cierre de la serie
Esta fue la curiosidad número 7 de 7.
Durante esta semana publiqué datos que rompen intuiciones sobre nuestro oficio:
- Empresas que pagan millones a gente por romper sus productos (Día 1)
- Compañías que despliegan a millones de dispositivos sin rollback (Día 2)
- Equipos que rompen su propia infraestructura a propósito (Día 3)
- La realidad de que el 40% de los bugs los encuentra el usuario (Día 4)
- La técnica de 0 segundos que encuentra bugs reales (Día 5)
- El hecho de que los videojuegos más vendidos salieron con 40+ bugs (Día 6)
- Y hoy: cómo la aviación lleva décadas haciendo QA a un nivel que el software comercial apenas está descubriendo
El hilo conductor es el mismo: la calidad no es ausencia de bugs. Es criterio para decidir qué importa.
Google decide que vale la pena pagar $12M por bugs. Tesla decide hacer canary deployments en autos reales. Netflix decide romper su infraestructura antes que la realidad. La aviación decide que algunos bugs no pueden existir nunca.
Ninguna de esas decisiones es “correcta” por sí sola. Cada una responde a su contexto.
Tu trabajo como QA no es replicar lo que hace Netflix o lo que hace la aviación. Es entender tu contexto lo suficientemente bien para tomar decisiones informadas. Ese criterio es el que te hace mejor QA — no las herramientas que usas.
Gracias por leer esta semana. Si te sirvió, compártela con alguien que esté empezando en QA.
Próxima semana: Llega ISTQB sin humo — una sección completa del blog dedicada a la certificación, pero contada desde bugs reales, no desde el syllabus. Los suscriptores del newsletter la van a ver primero.