Hablar hoy de transformación digital supone hablar, casi inevitablemente, de velocidad y no solo de software o hardware. Las organizaciones necesitan automatizar, mejorar su eficiencia, digitalizar procesos y responder a un mercado que exige innovación continua. A todo ello se ha sumado la IA, que está acelerando todavía más la capacidad de las compañías para desarrollar y poner en marcha nuevas soluciones.
Pero cuanto más rápido construimos más importante resulta preguntarse si estamos construyendo realmente lo que necesitamos.
No basta con demostrar que una aplicación funciona técnicamente. Una solución puede superar todas sus pruebas y llegar correctamente a producción y, aun así, no resolver la necesidad para la que fue creada, no facilitar el trabajo de los usuarios, no encajar en los procesos de la organización o no generar el valor que justificó la inversión.
Esta es una de las grandes paradojas de los proyectos tecnológicos, disponer de buena tecnología, profesionales cualificados y recursos suficientes y, pese a ello, terminar entregando algo que no resuelve el problema original. Y es que, muchas veces la causa no está en una carencia técnica sino en cuándo empezamos a hablar de calidad.
Con demasiada frecuencia QA entra en escena cuando gran parte del proyecto ya está construido. El equipo técnico ha desarrollado la solución, las fechas están comprometidas y la llegada a producción se aproxima. Es entonces cuando aparecen validaciones improvisadas, criterios de aceptación poco definidos o usuarios que deben probar una solución deprisa, sin siquiera haber participado suficientemente durante el proceso.
De este modo, la calidad acaba convertida en una última barrera antes de producción cuando, en realidad, debería formar parte de las decisiones desde el principio.
La perspectiva cambia cuando QA participa desde las primeras etapas. Su función deja entonces de centrarse exclusivamente en encontrar errores y empieza a plantear preguntas mucho más relevantes, ¿Cómo sabremos que hemos conseguido el resultado esperado? ¿Qué necesita realmente el usuario? ¿Qué condiciones deben cumplirse para considerar válida la solución? ¿Qué riesgos debemos abordar antes de seguir avanzando? La cuestión y no es hacer más pruebas, sino definir previamente qué significa hacerlo bien. Y ahí es donde QA necesita evolucionar.
Durante años, el aseguramiento de la calidad del software se ha asociado principalmente al testing previo a la puesta en producción. Las pruebas siguen siendo imprescindibles, pero reducir QA a esa función limita su verdadero potencial.
QA debe ayudar a conectar las distintas perspectivas de un proyecto. Negocio conoce la necesidad, Tecnología construye la solución y los usuarios deben comprobar que responde a la realidad. Para que todas estas visiones estén alineadas necesitamos criterios de aceptación compartidos, trazabilidad entre las necesidades iniciales y las soluciones desarrolladas y, mecanismos claros para gestionar los hallazgos.
También debemos cambiar la forma de entender las pruebas de aceptación de usuario, las UAT. No deberían convertirse en un último trámite realizado a pocos días de producción por usuarios que apenas disponen de tiempo entre sus responsabilidades habituales. La aceptación debe construirse durante el proyecto y no aparecer como una comprobación de emergencia al final.
Lo mismo sucede cuando encontramos defectos. Que algo falle forma parte de cualquier proyecto. Lo importante es disponer de un modelo que permita identificar el problema, valorar su impacto, corregirlo y aprender de lo ocurrido.
Esto es mucho más que testing. Significa conseguir que negocio, tecnología y usuarios compartan una misma definición de éxito durante todo el proyecto. Eso es gobernar la calidad.
La necesidad de hacerlo adquiere todavía más importancia en un momento en el que la inteligencia artificial está incrementando la velocidad de desarrollo. La IA puede ayudarnos a analizar información, refinar requisitos, generar escenarios, diseñar pruebas y automatizar tareas.
Pero existe un riesgo evidente, también puede ayudarnos a equivocarnos más deprisa. Si aceleramos la construcción sin mejorar nuestra capacidad para decidir qué debemos construir podemos obtener soluciones técnicamente impecables que nos lleven mucho más rápido en la dirección equivocada.
Por eso, una mayor velocidad debe ir acompañada de una mayor capacidad de decisión. Necesitamos criterios claros, mecanismos para identificar y priorizar riesgos y una visión definida de aquellos ámbitos en los que la intervención humana sigue siendo imprescindible.
El World Quality Report 2025-26 de Capgemini refleja precisamente esta evolución. La IA generativa está ganando terreno en la ingeniería de calidad y ofrece posibilidades en ámbitos como el refinamiento de requisitos o el diseño de pruebas. Sin embargo, muchas organizaciones todavía tienen dificultades para convertir estas capacidades en una mejora estable de sus procesos de calidad.
La conclusión es clara: la tecnología puede ayudarnos a validar más información y automatizar más tareas, pero primero necesitamos saber qué queremos validar y por qué.
La evolución de QA no debería consistir simplemente en hacer más testing o hacerlo más rápido. El verdadero cambio pasa por desarrollar una capacidad permanente para asegurar la calidad.
Ese es el enfoque de QA Coach, ayudar a las organizaciones a construir un modelo propio de calidad que integre estrategia, gobierno y cultura adaptado a su nivel de madurez y a su realidad.
El propósito es acompañar a los equipos para que la calidad forme parte de su manera de tomar decisiones, utilizando criterios compartidos, aplicando la IA allí donde realmente aporta valor y convirtiendo cada entrega en una fuente de aprendizaje para la siguiente.
Y es la calidad no puede depender de una persona concreta, de una fase determinada ni de un departamento. La calidad es una responsabilidad colectiva.
Empieza en el negocio cuando se define la necesidad, continúa en TI cuando esa necesidad se transforma en una solución, pasa por los usuarios cuando comprueban si funciona en el mundo real, y alcanza también a quienes gobiernan el proyecto, responsables de mantener alineadas todas esas perspectivas.
Las pruebas siguen siendo imprescindibles, aunque reducir QA a esa función limita su verdadero potencial
Por eso, asegurar la calidad en el desarrollo de software no puede seguir siendo una conversación reservada para el final ni una responsabilidad exclusiva de QA.
La conversación debe comenzar mucho antes, esto es, cuando todavía estamos definiendo el problema, concretando las necesidades y estableciendo qué significa tener éxito. Porque si hoy podemos construir más rápido que nunca, nuestra verdadera ventaja no estará únicamente en desarrollar antes, lo estará en saber qué merece la pena construir y en asegurarnos de que funciona.
Lily Rodríguez, Gerente del Área de Calidad de LedaMC
