Hay defectos que pueden desaparecer cuando cambiamos el indicador. Y no es que se corrijan, prevengan o se detecten antes. Simplemente no aparecen en el cuadro de mando porque la organización ha empezado a mirar otra cosa: casos generados, porcentajes de automatización…
Este efecto se puede ver intensificado por la llegada de la IA porque con ella las métricas de actividad mejoran con rapidez. Pero la calidad tiene que responder a otra pregunta, ¿qué está llegando a producción?
Y lo paradójico es que, mientras las organizaciones incorporan cada vez más IA al testing, los defectos no disminuyen necesariamente. Incluso en algunos casos aumentan.
Así queda reflejado en el State of Digital Quality in Functional Testing 2026, en el que más del 92% de los encuestados afirma utilizar IA en el proceso de testing frente al 62% del año anterior. Sin embargo, el 29 % declara que ha aumentado el número o la severidad de los defectos funcionales, mientras que un 15 % señala que han crecido ambas dimensiones.
Generando más pruebas, más rápido, se observa un deterioro de la calidad. Pero correlación no significa causalidad y el estudio no demuestra que la IA sea la causa de ese deterioro. Pero sí cuestiona una cosa: aumentar la capacidad de testing no implica que se reduzcan los defectos.
Podemos mejorar todos los indicadores de actividad de testing sin mejorar el resultado que realmente importa: la calidad del software entregado.
Más pruebas no significan necesariamente más riesgo cubierto
¿Cómo se puede generar más pruebas y, al mismo tiempo, encontrar más defectos o defectos más graves? Para responder, tenemos que empezar por distinguir entre aumentar la capacidad de testing y mejorar su efectividad.
Según el estudio, los usos más frecuentes de la IA en testing son crear casos de prueba, con un 65 %; escribir scripts de automatización, con un 62 %; e identificar carencias de cobertura, con un 48 %. Son capacidades útiles, pero sus resultados suelen expresarse mediante métricas de actividad: casos generados, porcentaje de automatización, ejecuciones completadas o reducción del tiempo de regresión.
Pero, como decíamos, no podemos confundir actividad con efectividad. Una batería puede crecer incorporando nuevas variantes de caminos ya conocidos y seguir dejando fuera escenarios importantes. Si un riesgo no aparece en los requisitos, nadie lo ha formulado o depende del comportamiento real del usuario, generar más pruebas no garantiza que vaya a quedar cubierto.
Y no podemos olvidar que la IA también acelera el desarrollo y aumenta el volumen de cambios que llega a QA. El propio informe señala que el 79 % de los encuestados percibe un impacto moderado o significativo de la IA en desarrollo, frente al 72 % que lo observa en testing.
El problema, entonces, no es solo si testing ejecuta más rápido. Es si su capacidad para comprender y cubrir el riesgo crece al mismo ritmo que el cambio. Si no lo hace, la organización puede automatizar más y reducir el tiempo de regresión mientras aumentan los defectos que atraviesan sus controles.
Cinco indicadores para saber si la calidad mejora de verdad
Para saber si de verdad estamos protegiendo el producto, las métricas de actividad no bastan. Hay que medir qué defectos atraviesan los controles, qué impacto tienen y cuánto esfuerzo cuesta corregirlos.
Y para ello es necesario observar lo que sucede después de ejecutar las pruebas. No hablamos de añadir más métricas al cuadro de mando, sino de responder cinco preguntas:
1. ¿Cuántos defectos escapan?
El defect escape muestra qué proporción se detecta después de la fase en la que debería haberse contenido, especialmente en producción.
2. ¿Qué gravedad tienen?
El número de incidencias debe ponderarse por su impacto. Un defecto menor no equivale a una interrupción crítica, una pérdida económica o una exposición de información.
3. ¿Cuánto trabajo obligan a repetir?
El retrabajo incluye corrección, análisis, repetición de pruebas, coordinación y redespliegue. Si el ahorro obtenido con IA reaparece aquí, la mejora es solo parcial.
4. ¿Qué coste generan?
El coste de la no calidad incorpora las consecuencias técnicas, operativas y económicas del defecto, desde el soporte hasta la indisponibilidad o el coste de oportunidad.
5. ¿Cómo se relacionan con el software entregado?
La calidad por unidad funcional nos permite saber si encontramos más defectos porque entregamos más software o porque estamos entregando peor.
Cuando respondemos y conectamos estas cinco preguntas, podemos saber si el testing está reduciendo el riesgo o simplemente aumentando su actividad.
De medir la actividad a gobernar la calidad
Por mucho que la IA amplíe la capacidad para generar, ejecutar y analizar pruebas, la decisión sobre qué merece probarse, qué evidencia es suficiente y qué riesgos son aceptables sigue exigiendo criterio humano.
Y el informe lo confirma: el 86,1 % de los encuestados considera extremadamente importante la intervención humana en el testing funcional, sobre todo para aportar feedback cualitativo, revisar el trabajo entre profesionales y diseñar las pruebas teniendo en cuenta el comportamiento real de los usuarios.
La automatización seguirá avanzando, pero el control sobre sus resultados tiene que hacerlo también. Para saber si realmente estamos mejorando, hay que conectar el software entregado con los defectos que llegan a producción, su severidad, el retrabajo y el coste de no calidad. De lo contrario, podemos estar simplemente trasladando el esfuerzo a incidencias y correcciones posteriores.
En LedaMC ayudamos a las organizaciones a establecer referencias comparables para evaluar la calidad del software, identificar dónde se pierde y decidir dónde intervenir: desde los requisitos y la estrategia de pruebas hasta la gestión de proveedores.
Ahí está la diferencia entre medir para informar y medir para gobernar. Más datos no tienen por qué aportar más valor. Necesitamos aquellos que nos permiten saber dónde actuar y comprobar si las decisiones están dando resultado.
