¿Cuánto cuesta no probar? El caso de negocio de la calidad
Las pruebas de software se ven como un costo que retrasa entregas porque su beneficio es intangible: los incidentes evitados. Justificarlas exige traducirlas a valor financiero y menor riesgo. Además, confundir aseguramiento de calidad y pruebas lleva a presupuestar mal la prevención y la detección.
En el entorno corporativo, la inversión en actividades de verificación suele percibirse como un centro de costos o una fricción que retrasa las fechas de entrega. Esta percepción surge porque el beneficio principal de probar software es intangible: consiste precisamente en los incidentes, pérdidas monetarias e interrupciones operativas que no llegaron a ocurrir. Para la alta dirección y los líderes de producto, justificar estos recursos exige traducir las actividades técnicas a indicadores de valor financiero, mitigación de riesgos y eficiencia operativa.
A esta dificultad de justificación se suma una confusión conceptual extendida en las organizaciones, donde los términos de aseguramiento de la calidad y pruebas suelen tratarse de forma intercambiable. Cuando una empresa confunde la mejora de los métodos de trabajo con la revisión directa del sistema, presupuesta de manera inadecuada tanto la prevención como la detección. Comprender el costo real de prescindir de la calidad requiere diferenciar con precisión ambos frentes.
Definiciones formales: QA, QC y pruebas
De acuerdo con el estándar internacional del temario ISTQB CTFL (versión 4.0), las responsabilidades del proceso y del producto se delimitan de la siguiente forma:
- Aseguramiento de la calidad (Quality Assurance - QA): Es un enfoque preventivo y orientado a los procesos, cuyo propósito es la implementación y mejora continua de los métodos de trabajo. Se fundamenta en la premisa de que seguir un proceso adecuado generará, por consecuencia, un producto con los niveles requeridos de calidad. Aplica tanto al desarrollo como a las actividades de prueba y constituye una responsabilidad compartida por todos los involucrados en el proyecto.
- Control de calidad (Quality Control - QC): Es un enfoque correctivo y orientado al producto terminado, centrado en las actividades que respaldan la consecución de los niveles de calidad esperados. Abarca mecanismos de inspección directa para evaluar si el software satisface las especificaciones establecidas.
- Pruebas de software (Testing): Representan una de las formas primordiales del control de calidad. Consisten en la ejecución, análisis y evaluación dinámica o estática del comportamiento de un componente o sistema para identificar defectos y medir su nivel de riesgo.
| Concepto | Enfoque primordial | Naturaleza operativa | Interrogante fundamental |
|---|---|---|---|
| Aseguramiento de la calidad (QA) | Procesos de trabajo | Preventiva | ¿Estamos construyendo la solución mediante el proceso correcto? |
| Control de calidad (QC) | Producto o entregable | Correctiva | ¿El software construido cumple con las especificaciones acordadas? |
| Pruebas de software | Forma específica de QC | Evaluativa / Correctiva | ¿Qué defectos contiene el sistema y qué riesgos operacionales revela? |
El mito de la curva de costos y la realidad operativa
La interacción entre el aseguramiento de la calidad, el control de calidad y las pruebas de software establece una cadena de valor clara. Mientras el aseguramiento de la calidad optimiza la prevención de defectos en el proceso de desarrollo, el control y las pruebas ejecutan la detección de defectos y facilitan la corrección de errores en los entregables.
Durante décadas, la literatura técnica repitió la llamada "curva 1:10:100" o multiplicadores lineales exactos supuestamente originados en el IBM Systems Sciences Institute. Autores como Laurent Bossavit y Hillel Wayne han demostrado que dicho estudio formal nunca existió como publicación científica, y análisis empíricos como el de Menzies et al. (2016, sobre 171 proyectos) concluyen que un multiplicador exponencial rígido no representa una ley universal de la ingeniería de software.
No obstante, la dirección del costo sí guarda respaldo empírico cuando se contextualiza con rigor técnico. Barry Boehm observó que resolver un problema de software tras el despliegue suele costar cerca de 100 veces más que detectarlo durante las fases de requerimientos y diseño en sistemas grandes y críticos; en sistemas pequeños o de bajo impacto, la relación ronda 5 a 1. El costo de postergar la corrección radica en el retrabajo acumulado y el impacto sobre la operación.
El costo interno de omitir la calidad se refleja con fuerza en la capacidad de los equipos de ingeniería. El estudio The Developer Coefficient elaborado por Stripe reveló que el desarrollador promedio consume más de 17 horas semanales en labores de mantenimiento y depuración técnica. De este tiempo, aproximadamente cuatro horas semanales se destinan directamente a corregir código defectuoso, consumiendo en conjunto cerca del 40% de la semana laboral de los profesionistas.
Asimismo, las investigaciones del consorcio DORA (DevOps Research and Assessment) invalidan el argumento gerencial de que la exhaustividad en pruebas merma la velocidad de entrega comercial. Los análisis de DORA demuestran que la estabilidad operativa y la velocidad de entrega conviven en los equipos de mayor desempeño, registrando tasas sustancialmente menores de fallas en los despliegues respecto a organizaciones con prácticas de calidad deficientes.
El impacto en el negocio: evidencia de la falta de pruebas
El reporte macroeconómico del Consortium for Information & Software Quality (CISQ) estimó en al menos 2.41 billones de dólares el costo del software de baja calidad en Estados Unidos durante 2022, y calculó por separado la deuda técnica acumulada en cerca de 1.52 billones de dólares adicionales. Sin embargo, más allá de cifras agregadas basadas en supuestos indirectos, la gravedad económica y operativa se constata en incidentes corporativos documentados:
- Pérdida financiera pura: El 1 de agosto de 2012, un despliegue deficiente en Knight Capital reactivó código obsoleto ("Power Peg") en uno de sus servidores operativos. En 45 minutos, el sistema ejecutó millones de órdenes erróneas, provocando pérdidas de más de 460 millones de dólares, según la SEC, y una multa de la Securities and Exchange Commission (SEC) de 12 millones por infringir la Market Access Rule, lo que forzó la venta de la firma.
- Riesgo regulatorio y reputacional regional: En México, el 12 de septiembre de 2021, una actualización fallida de sistemas centrales en BBVA México interrumpió las operaciones de banca móvil y cajeros automáticos, afectando a cerca de 24 millones de usuarios y derivando en aproximadamente 80,000 reclamaciones formales. La Comisión Nacional Bancaria y de Valores (CNBV) intervino bajo la Circular Única de Bancos, la cual obliga a reportar contingencias operativas mayores a 60 minutos y exige la ejecución efectiva de pruebas integrales en configuraciones y funcionalidades.
- Falla logística a escala global: La actualización defectuosa del sensor Falcon de CrowdStrike el 19 de julio de 2024 inhabilitó aproximadamente 8.5 millones de computadoras con sistemas operativos Windows en aeropuertos, hospitales y bancos. Como consecuencia de la interrupción, la aerolínea Delta reportó cancelaciones de más de 7,000 vuelos y un impacto financiero superior a los 550 millones de dólares en costos no planeados y pérdida de ingresos.
- Costo humano y judicial: Defectos en el diseño del software MCAS del avión Boeing 737 MAX derivaron en 346 muertes humanas y acuerdos judiciales por más de 2,500 millones de dólares. De igual modo, los defectos del sistema contable Horizon en el servicio postal del Reino Unido condujeron a la condena injusta de 983 administradores de sucursales y se vincularon a al menos 13 suicidios, catalogándose como una de las fallas institucionales y tecnológicas más severas de la historia legal británica.
Conclusión
El valor del aseguramiento de la calidad y de las pruebas técnicas no debe medirse únicamente por la cantidad de reportes generados en un tablero interno, sino por su capacidad directa para proteger la rentabilidad, la estabilidad operativa y la reputación de la organización. Reducir los presupuestos destinados a probar el software no elimina los costos asociados a las fallas; simplemente transfiere esos gastos hacia la operación productiva, el soporte técnico y el marco legal, donde la corrección resulta sustancialmente más costosa.
Asimismo, las empresas deben dimensionar sus esfuerzos de calidad de forma proporcional al riesgo de su contexto operativo. No todo sistema requiere el mismo rigor que un dispositivo médico o un procesador de transacciones bursátiles, pero prescindir de la distinción entre asegurar los procesos y evaluar los productos compromete la viabilidad técnica del negocio frente a reguladores, clientes y competidores.
Fuentes
- Boehm, B., & Basili, V. R. (2001). Software Defect Reduction Top 10 List. IEEE Computer, 34(1), 135-137.
- Consortium for Information & Software Quality (CISQ). (2022). The Cost of Poor Software Quality in the US: A 2022 Report.
- DevOps Research and Assessment (DORA). (2019, 2024). Accelerate State of DevOps Report. Google Cloud.
- International Software Testing Qualifications Board (ISTQB). (2023). Certified Tester Foundation Level (CTFL) Syllabus v4.0.
- Menzies, T., Nichols, W., Shull, F., & Layman, L. (2016). Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle. arXiv:1609.04886.
- Stripe & Harris Poll. (2018). The Developer Coefficient: How software engineers are fueling the next global economic growth.
- U.S. Securities and Exchange Commission (SEC). (2013). Press Release 2013-222: SEC Charges Knight Capital With Violations of Market Access Rule.