Noticias

Calidad en el desarrollo de software: cuando el software funciona, pero el proyecto no

31 agosto, 2026 | lectura 4 min.

Llevamos mucho tiempo hablando de transformación digital, de eficiencia operativa, de automatizar procesos y, ahora, casi sin parar, de inteligencia artificial. Y no solo se habla, sino que las organizaciones invierten más y más recursos en desarrollar soluciones digitales con mayor rapidez y responder a un mercado que nos pide innovación constante.

Y mientras, entre tanta conversación, hay una pregunta que en muchas organizaciones sigue sin tener una respuesta clara:

¿Quién se asegura de que lo que estamos construyendo realmente funciona como se espera?

No hablamos únicamente de que funcione técnicamente. Hablamos de que funcione para el negocio, para los usuarios, que encaje en los procesos de la organización y genere el valor que justificó la inversión.

Porque sí, sucede más de lo que creemos, que una aplicación supera todas las pruebas técnicas y, aun así, no resuelve el problema para el que fue creada.

El problema no es la tecnología. Es el momento

Los profesionales de QA vemos con demasiada frecuencia cómo muchos proyectos que parecen arrancar de forma sólida, con presupuesto y un buen equipo técnico, llegan a producción con validaciones improvisadas, criterios de aceptación vagos y usuarios que nadie ha involucrado lo suficiente.

Esto no tiene por qué ser un problema de capacidad técnica. Muchas veces, simplemente, la calidad entró demasiado tarde en la conversación y por eso nadie validó con tiempo suficiente que aquello que se estaba construyendo era lo que se necesitaba.

Cuando QA entra al final, solo puede comprobar si algo funciona o detectar qué está fallando. Cuando participa desde el principio, puede ayudar a responder preguntas mucho más importantes: ¿qué tiene que ocurrir para considerar que este proyecto ha tenido éxito?, ¿qué espera realmente el usuario?, ¿qué riesgos debemos validar antes de seguir avanzando?

La diferencia es enorme. No es probar mejor, sino definir antes qué significa hacerlo bien. Y esto cambia por completo el valor que aporta.

QA no puede ser solo testing

Durante mucho tiempo se ha asociado el aseguramiento de la calidad en desarrollo de software con la ejecución de pruebas antes de la puesta en producción. Esa función aún es imprescindible, pero también insuficiente.

QA ha sido históricamente la bisagra entre lo que se construye y lo que se necesita. Y este rol implica ampliar la mirada más allá de encontrar defectos.

Tenemos que ser capaces de establecer criterios de aceptación que negocio y TI entiendan de la misma manera. Hay que mantener la trazabilidad entre las necesidades iniciales y las soluciones desarrolladas. Esto también cambia la forma de entender las pruebas de aceptación de usuario (UAT), que tienen que estar correctamente estructuradas y no ser una validación apresurada justo antes de producción, realizada por usuarios sin apenas tiempo entre sus responsabilidades habituales. Y cuando algo falle, que algo lo hará, tenemos que disponer de mecanismos claros para gestionar los hallazgos, corregirlos y aprender de ellos.

Y esto es mucho más que testing. Es conseguir que negocio, tecnología y usuarios trabajen con una misma definición de éxito durante todo el proyecto. Es gobernar la calidad.

Más velocidad exige más criterio

Y ahora que la velocidad de entrega es mucho mayor es incluso más necesaria esta forma de entender la calidad. La capacidad de acelerar el desarrollo que nos da la IA puede hacernos avanzar mucho más rápido en una dirección equivocada.

Por eso, cuanto mayor sea la velocidad, también tiene que aumentar nuestra capacidad para establecer criterios claros, priorizar los riesgos y decidir dónde sigue siendo imprescindible la intervención humana.

El World Quality Report 2025-26 de Capgemini refleja precisamente este cambio. La IA generativa está ganando terreno en ingeniería de calidad y ofrece muchas posibilidades en ámbitos como el refinamiento de requisitos o el diseño de pruebas. Sin embargo, el propio informe advierte de que muchas organizaciones siguen teniendo dificultades para convertir ese uso de IA en una mejora estable de sus procesos de calidad.

Está claro que la IA puede ayudarnos a revisar más información, generar más escenarios y automatizar determinadas tareas, pero antes necesitamos saber qué queremos validar y por qué.

De ejecutar pruebas a crear una capacidad de calidad

La evolución natural, por tanto, no sería hacer más testing ni hacerlo más rápido, sino desarrollar una capacidad permanente para asegurar la calidad.

Ese es precisamente el enfoque de QA Coach: ayudar a las organizaciones a crear un modelo propio que integre estrategia, gobierno y cultura de calidad, adaptado siempre a su nivel de madurez y a su realidad.

Esto supone acompañar a los equipos para construir una cultura de calidad donde las decisiones se toman con criterios compartidos, donde la IA se utiliza allí donde de verdad aporta valor y donde cada entrega deja conocimiento para mejorar la siguiente.

La calidad no debería depender de una persona concreta ni de una fase determinada del proyecto. Ni tampoco es un departamento. La calidad es una forma de trabajar y pertenece a todos. Pertenece al negocio cuando define sus necesidades, a TI cuando las transforma en soluciones, a los usuarios cuando validan que funcionan en el mundo real y a quienes gobiernan el proyecto para mantener alineadas todas esas perspectivas.

Y es por eso que asegurar la calidad en desarrollo de software no puede seguir siendo una conversación reservada para el final del proyecto ni una responsabilidad exclusiva del equipo de QA. Cuanto antes entre esa conversación en un proyecto, mayores serán sus posibilidades de éxito.


Artículo de Lily Rodríguez – Gerente del Área de Calidad de LedaMC