Aunque lleguemos a desarrollar a más velocidad no nos servirá de nada si nos damos cuenta tarde de que la solución construida es la equivocada
Por Lilybeth Rodríguez, Gerente del Área de Calidad de LedaMC
Durante años, la transformación digital ha llevado a las organizaciones a perseguir un objetivo aparentemente sencillo: hacer más, hacerlo mejor y, sobre todo, hacerlo más rápido. Automatización, eficiencia operativa, nuevos productos digitales, innovación constante… Y ahora, con especial intensidad, inteligencia artificial. La presión por acelerar las entregas no deja de crecer, mientras las empresas destinan cada vez más recursos a construir soluciones capaces de responder a un mercado que cambia a una velocidad difícil de seguir.
Pero hay una cuestión que en medio de toda esta carrera continúa sin resolverse del todo ¿Quién se asegura de que aquello que estamos construyendo es realmente lo que necesitamos?
Porque que una solución funcione técnicamente no significa necesariamente que haya sido un éxito. Tiene que responder a las necesidades del negocio, ser útil para quienes van a utilizarla, integrarse en los procesos de la organización y, en última instancia, generar el valor que justificó su desarrollo.
Esta diferencia es más habitual de lo que parece. Un producto puede superar las pruebas técnicas previstas y llegar a producción sin errores evidentes y, aun así, no solucionar adecuadamente el problema para el que fue creado. En esos casos, el fallo no está necesariamente en la tecnología ni en la capacidad del equipo. Muchas veces está en algo mucho más básico y es que la calidad empezó a formar parte de la conversación demasiado tarde.
Quienes trabajamos en QA conocemos bien ese escenario. Proyectos que comienzan con buenos equipos, presupuesto y una planificación aparentemente sólida terminan acercándose a producción con criterios de aceptación poco definidos, validaciones improvisadas y usuarios que apenas han tenido oportunidad de participar. Cuando esto ocurre, el margen para corregir el rumbo es ya muy reducido.
Y aquí está una de las grandes transformaciones que necesita el aseguramiento de la calidad: dejar de entender QA como una actividad que se activa al final para comprobar si algo funciona.
Cuando QA participa desde las primeras etapas, las preguntas cambian. Ya no se trata únicamente de identificar qué está fallando, sino de establecer qué significa tener éxito. ¿Qué necesita realmente el usuario? ¿Qué condiciones deben cumplirse para considerar que una solución responde a las expectativas del negocio? ¿Cuáles son los riesgos que deberíamos validar antes de continuar avanzando?
La diferencia no es menor. No consiste en probar mejor, sino en definir antes qué significa hacerlo bien.
Durante mucho tiempo QA ha estado asociado principalmente a la ejecución de pruebas antes de una puesta en producción. El testing sigue siendo una pieza imprescindible y, por supuesto, no pierde relevancia. Pero reducir el aseguramiento de la calidad a esa actividad supone desaprovechar buena parte del valor que puede aportar.
Históricamente, QA ha actuado como una especie de bisagra entre lo que la organización necesita y lo que tecnología construye. Hoy esa función requiere una mirada mucho más amplia. Significa, por ejemplo, establecer criterios de aceptación que negocio y TI interpreten de la misma manera, mantener la trazabilidad entre las necesidades iniciales y la solución desarrollada y anticipar los riesgos en lugar de limitarse a descubrirlos cuando ya se han materializado.
También implica replantear cómo abordamos las pruebas de aceptación de usuario, las conocidas UAT. No deberían convertirse en una última barrera antes de producción, ejecutada deprisa por usuarios que tienen que compaginar la validación con sus responsabilidades habituales. Una UAT eficaz necesita preparación, criterios claros, participación adecuada y tiempo suficiente para que los usuarios puedan validar la solución desde la perspectiva del negocio y de su realidad diaria.
Y, naturalmente, habrá hallazgos. Siempre los habrá. La cuestión es disponer de mecanismos claros para gestionarlos, priorizarlos, corregirlos y, algo todavía más importante, convertirlos en conocimiento que ayude a evitar que los mismos problemas vuelvan a repetirse.
Todo esto nos lleva a una conclusión, QA es mucho más que testing. Es una forma de conseguir que negocio, tecnología y usuarios compartan una misma definición de éxito a lo largo de todo el proyecto. En otras palabras, hablamos de gobernar la calidad.
Esta necesidad se vuelve todavía más evidente en un contexto en el que la velocidad de desarrollo se ha multiplicado. La inteligencia artificial está acelerando determinadas fases del ciclo de vida y puede ayudarnos a generar código, analizar información, diseñar escenarios de prueba o refinar requisitos. Pero existe una paradoja que no deberíamos ignorar y es que cuanto más rápido podemos construir, más rápido podemos avanzar también en una dirección equivocada.
Por eso, acelerar no puede significar simplemente producir más. A mayor velocidad de entrega necesitamos también mayor capacidad para establecer criterios claros, identificar y priorizar riesgos y determinar en qué momentos la intervención humana continúa siendo imprescindible.
El World Quality Report 2025-26 de Capgemini refleja precisamente esta evolución. La IA generativa está ganando presencia en la ingeniería de calidad y abre oportunidades relevantes en ámbitos como el refinamiento de requisitos y el diseño de pruebas. Sin embargo, el informe también señala que muchas organizaciones todavía encuentran dificultades para transformar estos usos de la IA en mejoras sostenibles y consolidadas dentro de sus procesos de calidad.
La cuestión, por tanto, no es si podemos utilizar IA para revisar más información, generar más escenarios o automatizar más tareas. Podemos hacerlo. La cuestión previa es mucho más importante: saber qué queremos validar, por qué necesitamos validarlo y qué impacto tiene aquello que estamos construyendo.
De ahí que la evolución natural de QA no deba consistir en hacer cada vez más testing, ni únicamente en hacerlo más rápido. El verdadero salto está en desarrollar una capacidad permanente para asegurar la calidad desde el inicio y durante todo el ciclo de vida de una solución.
Ese es precisamente el enfoque de QA Coach: ayudar a las organizaciones a construir un modelo propio de calidad que combine estrategia, gobierno y cultura, siempre adaptado a su nivel de madurez, sus necesidades y su realidad. No se trata de imponer una fórmula universal, sino de acompañar a los equipos para que desarrollen una manera de trabajar en la que la calidad forme parte de las decisiones y no aparezca únicamente como una comprobación final.
Esto significa crear una cultura en la que negocio, tecnología y usuarios compartan criterios, en la que la IA se utilice allí donde realmente aporta valor y en la que cada entrega genere conocimiento útil para mejorar la siguiente. Porque la calidad no debería depender de una persona concreta, de un departamento o de una fase determinada del proyecto.
La calidad pertenece a todos. Al negocio, cuando define qué necesita. A TI, cuando transforma esas necesidades en soluciones. A los usuarios, cuando comprueban si esas soluciones funcionan realmente en el mundo real y, finalmente, a quienes gobiernan los proyectos, cuando consiguen mantener alineadas todas esas perspectivas y tomar decisiones con una visión común.
Por eso, asegurar la calidad en el desarrollo de software no puede seguir siendo una conversación que se mantiene en segundo plano hasta las últimas semanas de un proyecto, ni una responsabilidad que se deposita exclusivamente en el equipo de QA.
La calidad empieza mucho antes de ejecutar una prueba. Empieza cuando decidimos qué problema queremos resolver, cómo sabremos que lo hemos resuelto y qué riesgos estamos dispuestos, o no, a asumir.
En un entorno donde cada vez podemos construir más rápido, la ventaja no estará únicamente en nuestra capacidad para entregar. Estará en nuestra capacidad para saber qué merece la pena entregar y asegurarnos de que lo hacemos bien desde el principio.
Arriba, en la foto, Lilybeth Rodríguez, Gerente del Área de Calidad de LedaMC
