Software quality is not a housekeeping issue. CISQ estimated a $2.41 trillion US cost in 2022, after $2.84 trillion in 2018 and $2.08 trillion in 2020. The same report estimated accumulated technical debt at about $1.52 trillion. These are broad economic estimates, not a price tag for skipped testing alone.
La calidad del software no es una tarea menor de mantenimiento. CISQ estimó un coste de 2,41 billones de dólares en Estados Unidos en 2022, después de 2,84 billones en 2018 y 2,08 billones en 2020. El mismo informe estimó la deuda técnica acumulada en unos 1,52 billones. Son estimaciones económicas amplias, no el precio aislado de omitir testing.
The debate often mixes different problems. Unit tests examine small pieces, integration tests examine interactions, and coverage only records what ran. TDD changes the development sequence. Technical debt describes the future burden left behind.
El debate suele mezclar problemas diferentes. Las pruebas unitarias examinan piezas pequeñas, las de integración examinan interacciones y la cobertura solo registra qué se ejecutó. TDD cambia la secuencia de desarrollo. La deuda técnica describe la carga futura que queda.
A common vocabulary is only useful when teams turn software fundamentals into shared practice.
Un vocabulario común solo es útil cuando los equipos convierten los fundamentos del software en una práctica compartida.
NIST put a narrower number on inadequate testing infrastructure. Its 2002 estimate was $59.5 billion, with $22.2 billion potentially avoidable through better infrastructure. That leaves a large residual even inside this model. Testing matters, but it is not the whole quality system.
NIST puso una cifra más estrecha a la infraestructura de testing inadecuada. Su estimación de 2002 fue de 59.500 millones de dólares, con 22.200 millones potencialmente evitables mediante una mejor infraestructura. Incluso dentro de este modelo queda un gran coste residual. El testing importa, pero no es todo el sistema de calidad.
Four IBM and Microsoft teams reported 40% to 90% lower pre-release defect density and about 15% to 35% more initial development time after adopting TDD. Separately, a 32-developer Microsoft team using NUnit after coding for one year reported a 20.9% decrease in test defect density. These results support possible benefits from automated testing while not proving a universal TDD effect or a mandatory test-first sequence.
Cuatro equipos de IBM y Microsoft informaron entre 40% y 90% menos densidad de defectos antes del lanzamiento y aproximadamente entre 15% y 35% más de tiempo inicial tras adoptar TDD. Por separado, un equipo de Microsoft de 32 desarrolladores que usó NUnit después de programar durante un año informó una reducción del 20,9% en la densidad de defectos de prueba. Estos resultados respaldan posibles beneficios de las pruebas automatizadas, pero no demuestran un efecto universal de TDD ni una secuencia test-first obligatoria.
The TDD evidence makes the bargain explicit: more initial effort can accompany fewer defects.
La evidencia sobre TDD hace explícito el intercambio: un mayor esfuerzo inicial puede acompañar a menos defectos.
Google's pyramid gives teams a useful bias toward fast unit tests. It does not establish a universal optimum. A classic experiment tested about one million inputs across 27 independently developed versions and still found correlated failures. Components can repeat the same mistake, so isolation is not enough.
La pirámide de Google ofrece a los equipos una preferencia útil por pruebas unitarias rápidas. No establece un óptimo universal. Un experimento clásico probó cerca de un millón de entradas en 27 versiones desarrolladas de forma independiente y encontró fallos correlacionados. Los componentes pueden repetir el mismo error, por lo que probarlos de forma aislada no basta.
Coverage answers a narrow question: did the test execute this code? Across more than 31,000 suites from five projects, coverage was only weakly associated with effectiveness after controlling for suite size. It still exposes completely untested code. What it cannot provide is a universal percentage that guarantees meaningful fault detection.
La cobertura responde a una pregunta estrecha: ¿la prueba ejecutó este código? En más de 31.000 suites de cinco proyectos, la cobertura solo se asoció débilmente con la eficacia tras controlar el tamaño de la suite. Sigue sirviendo para descubrir código sin probar. Lo que no ofrece es un porcentaje universal que garantice la detección de fallos significativos.
Continuous integration shortens the path from change to feedback, but flaky tests can make that feedback noisy. One study covered 34,544 open-source projects. Google reported that 1.5% of its test executions produced flaky outcomes. A separate empirical study examined 201 commits fixing flaky tests and identified recurring causes including asynchronous waits, concurrency, and test-order dependencies.
La integración continua acorta el camino entre un cambio y el feedback, pero las pruebas flaky pueden volver ruidosa esa respuesta. Un estudio abarcó 34.544 proyectos abiertos. Google informó que el 1,5% de sus ejecuciones produjo resultados flaky. Otro estudio empírico examinó 201 commits que corregían pruebas flaky e identificó causas recurrentes, como esperas asíncronas, concurrencia y dependencias del orden de las pruebas.
Technical debt is not only an engineering complaint. McKinsey reported a 10% lower bound, a 15% supplied midpoint, and a 20% upper bound for technology budgets diverted from new products. The roadmap must absorb that displaced capacity.
La deuda técnica no es solo una queja de ingeniería. McKinsey informó de un límite inferior del 10%, un punto medio aportado del 15% y un límite superior del 20% para los presupuestos tecnológicos desviados de nuevos productos. La hoja de ruta debe absorber esa capacidad desplazada.
Modern software inherits code, maintenance obligations, and vulnerabilities from its dependencies. Synopsys reported open source in 96% of audited codebases, vulnerabilities in 84%, and high-risk vulnerabilities in 74%. Testing can expose some failures, but it cannot exhaust every dependency state and attacker behavior. Secure engineering must also govern what enters the system and how teams respond.
El software moderno hereda código, obligaciones de mantenimiento y vulnerabilidades de sus dependencias. Synopsys informó de código abierto en el 96% de las bases auditadas, vulnerabilidades en el 84% y vulnerabilidades de alto riesgo en el 74%. El testing puede revelar algunos fallos, pero no puede agotar cada estado de dependencias y comportamiento atacante. La ingeniería segura también debe gobernar qué entra en el sistema y cómo responde el equipo.
Coverage, warning counts, and defect totals are signals, not definitions of quality. Once one signal becomes the target, teams can optimize the reported number while customer outcomes remain unchanged. The safer system combines small reviews, automated analysis, layered tests, dependency control, and production outcomes. No single score gets to declare victory.
La cobertura, los avisos y los defectos son señales, no definiciones de calidad. Cuando una señal se convierte en la meta, los equipos pueden optimizar la cifra informada mientras los resultados del cliente no cambian. El sistema más seguro combina revisiones pequeñas, análisis automatizado, pruebas por capas, control de dependencias y resultados en producción. Ninguna puntuación puede declarar la victoria por sí sola.
After governance checks the score, developers still make design and testing decisions in the code.
Después de revisar las métricas, los desarrolladores aún toman decisiones de diseño y testing en el código.
The economic exposure is enormous, but the evidence does not support one universal remedy. TDD may reduce pre-release defects, while coverage alone cannot certify effective testing. Flaky executions can pollute feedback, and audited codebases often contain serious dependency risks. Quality therefore depends on several defenses and on measuring outcomes, not one ritual or score.
La exposición económica es enorme, pero los datos no respaldan una solución universal. El TDD puede reducir los defectos antes del lanzamiento, mientras que la cobertura por sí sola no certifica pruebas eficaces. Las ejecuciones flaky pueden contaminar el feedback y las bases auditadas suelen contener riesgos graves en sus dependencias. Por tanto, la calidad depende de varias defensas y de medir resultados, no de un único ritual o puntuación.
Across more than 31,000 test suites from five projects, coverage was only weakly associated with effectiveness after controlling for test-suite size. Association for Computing Machinery
Stripe's survey estimated developers spent 17.3 hours weekly on maintenance, debugging, and bad code, approximately 42% of a working week. Stripe
Synopsys reported open source in 96% of audited codebases, vulnerabilities in 84%, and high-risk vulnerabilities in 74% in its 2024 sample. Synopsys
Four IBM and Microsoft teams using test-driven development reported 40% to 90% lower pre-release defect density than comparable conventionally developed projects. Springer
A multi-site family of six controlled replications found test-first sequencing did not consistently improve quality or productivity; process granularity and uniformity mattered more. Springer
Testing about one million inputs across 27 independently developed program versions revealed correlated failures, contradicting an assumption of independent implementation errors. Institute of Electrical and Electronics Engineers
A three-year industrial study examined 11 design patterns and found defect associations varied by pattern rather than moving uniformly in one direction. Institute of Electrical and Electronics Engineers
Research using 357 real faults from five projects found mutation-based scores more strongly related to real-fault detection than raw statement or branch coverage. Association for Computing Machinery
Google reported that approximately 1.5% of its test executions produced flaky outcomes, creating substantial noise at very large testing volumes. Google
The argument
Better testing infrastructure could reduce part of the bill, not erase it.
The industrial TDD teams reported 40% to 90% fewer pre-release defects and 15% to 35% more initial time.
Unit tests dominate the mix, but interactions still need direct testing.
Design rules help only when the dependency, pattern, and change fit the situation.
Flaky-test noise is documented through three separate evidence points.
This research is published in English and Spanish. Ver en español
La investigación detrás de esta presentación
La factura cayó después de 2018 y volvió a subir hasta 2,41 billones de dólares. Estos términos separan cantidad de pruebas, alcance y coste de ingeniería a largo plazo.
Hallazgos clave
CISQ estimó el coste estadounidense del software de mala calidad en 2,84 billones de dólares en 2018, 2,08 billones en 2020 y 2,41 billones en 2022. Consortium for Information & Software Quality
En más de 31.000 suites de cinco proyectos, la cobertura mostró una asociación débil con la eficacia tras controlar el tamaño de la suite. Association for Computing Machinery
La encuesta de Stripe estimó que los desarrolladores dedicaban 17,3 horas semanales a mantenimiento, depuración y código deficiente, aproximadamente el 42% de la semana. Stripe
Synopsys informó de código abierto en el 96% de las bases auditadas, vulnerabilidades en el 84% y vulnerabilidades de alto riesgo en el 74% en 2024. Synopsys
Cuatro equipos de IBM y Microsoft que usaron TDD registraron entre 40% y 90% menos defectos antes del lanzamiento que proyectos convencionales comparables. Springer
Una familia de seis réplicas controladas encontró que empezar por las pruebas no mejoraba consistentemente calidad o productividad; importaban más granularidad y regularidad. Springer
NIST estimó que los usuarios absorbían aproximadamente el 80% del coste económico de 2002 atribuido a una infraestructura de testing inadecuada. National Institute of Standards and Technology
Probar cerca de un millón de entradas en 27 versiones independientes reveló fallos correlacionados, contradiciendo la supuesta independencia de sus errores. Institute of Electrical and Electronics Engineers
Un estudio industrial de tres años examinó 11 patrones y encontró asociaciones con defectos diferentes según el patrón, sin una dirección uniforme. Institute of Electrical and Electronics Engineers
Una investigación con 357 fallos reales de cinco proyectos encontró que las puntuaciones de mutación se relacionaban mejor con la detección que la cobertura bruta. Association for Computing Machinery
Google informó que aproximadamente el 1,5% de sus ejecuciones producía resultados flaky, generando ruido considerable con volúmenes muy grandes. Google
El argumento
Una mejor infraestructura de testing podría reducir parte de la factura, no eliminarla.
Los equipos industriales con TDD informaron entre 40% y 90% menos defectos antes del lanzamiento y entre 15% y 35% más de tiempo inicial.
Las pruebas unitarias dominan la mezcla, pero las interacciones aún necesitan testing directo.
Las reglas de diseño ayudan solo cuando la dependencia, el patrón y el cambio encajan con la situación.
31.000 suites mostraron por qué la cobertura sola no certifica un testing eficaz.
El ruido de las pruebas flaky se documenta mediante tres evidencias separadas.
Esta investigación se publica en inglés y español. Read in English
