Cuanto más rápido construimos, más importante es saber qué estamos construyendo.
La inteligencia artificial y la automatización están acelerando como nunca el desarrollo de software. Pero correr más no garantiza llegar al lugar correcto.
Podemos desarrollar software más rápido que nunca. Podemos automatizar procesos, generar código, analizar grandes volúmenes de información y apoyarnos en inteligencia artificial para acelerar prácticamente cualquier fase del desarrollo. La tecnología nos permite correr. La pregunta es si estamos corriendo en la dirección correcta.
Porque hay algo que no ha cambiado al mismo ritmo que nuestra capacidad para construir y es la necesidad de asegurarnos de que lo que construimos sirve realmente para algo.
Una aplicación puede funcionar técnicamente y ser al mismo tiempo un fracaso para el negocio. Puede superar las pruebas previstas, cumplir los requisitos documentados y llegar a producción sin errores críticos pero no resolver el problema que originó el proyecto. Puede incluso ser impecable desde el punto de vista tecnológico y resultar poco útil para quienes tienen que utilizarla cada día.
¿Quién está asegurando que aquello que estamos construyendo es realmente lo que necesitamos?
Y quizá ahí esté uno de los dilemas que más necesitamos resolver en un momento en el que todo parece girar alrededor de la velocidad y no es otro que ¿Quién está asegurando que aquello que estamos construyendo es realmente lo que necesitamos?
La respuesta no debería aparecer en las últimas semanas del proyecto.
Índice de temas
Cuando la calidad llega tarde
Sin embargo, sigue siendo habitual que los equipos de QA reciban proyectos cuando buena parte de las decisiones importantes ya están tomadas. El equipo técnico está trabajando, el presupuesto está comprometido, los plazos aprietan y, de repente, llega el momento de validar. Es entonces cuando aparecen criterios de aceptación ambiguos, usuarios que apenas han participado y procesos de UAT organizados con prisas.
Y es que no suele ser un problema de falta de capacidad técnica. El problema es anterior. La calidad llegó tarde.
Y cuando QA llega tarde, su capacidad de influencia también se reduce. Puede comprobar si algo funciona, localizar defectos y ayudar a corregirlos pero, difícilmente, puede cuestionar a tiempo si se está construyendo la solución adecuada, si los requisitos reflejan realmente las necesidades del negocio o si los principales riesgos se están abordando antes de que sea demasiado costoso hacerlo.
Por eso, hablar de calidad hoy exige hablar de algo mucho más amplio que de testing.
El testing sigue siendo necesario. Nadie discute su importancia. Pero convertir QA en sinónimo de ejecutar pruebas es quedarse con una parte demasiado pequeña de lo que significa asegurar la calidad de una solución digital.
La verdadera solución empieza antes. Empieza cuando se definen los criterios que permitirán determinar si un proyecto ha tenido éxito, cuando negocio y tecnología acuerdan qué significa cada requisito, cuando existe trazabilidad entre la necesidad inicial y lo que finalmente se desarrolla y cuando los riesgos se identifican antes de que se conviertan en problemas.
Pero además, también cuando las pruebas de aceptación de usuario, las UAT, dejan de ser ese último trámite que se coloca justo antes de producción. Los usuarios no deberían recibir una solución prácticamente terminada para que con el tiempo que les dejan sus responsabilidades habituales decidan si aquello responde a sus necesidades. Una UAT eficaz necesita preparación, participación y criterios claros. En definitiva necesita formar parte del proyecto, no ser su examen final.
Y, todo ello sin olvidar que necesita asumir una realidad incómoda y es que, algo fallará. La calidad no consiste en conseguir que nunca aparezcan problemas. Consiste también en tener mecanismos para detectarlos, priorizarlos, resolverlos y aprender de ellos.
QA no debería limitarse a encontrar defectos; debería ayudar a crear las condiciones para que el equipo tenga claro qué significa hacer las cosas bien
Ese cambio de perspectiva es fundamental. QA no debería limitarse a encontrar defectos; debería ayudar a crear las condiciones para que el equipo tenga claro qué significa hacer las cosas bien.
Eso es gobernar la calidad.
Y resulta especialmente importante ahora, cuando la inteligencia artificial está modificando radicalmente nuestra capacidad para desarrollar y entregar software. La IA puede ayudarnos a analizar requisitos, generar escenarios, automatizar tareas y acelerar numerosas actividades de ingeniería de calidad. No obstante, existe un riesgo evidente y es que si somos capaces de construir diez veces más rápido también podemos equivocarnos diez veces más rápido.
La velocidad, por sí sola, no es una estrategia
Cuanto más aceleramos la entrega, más necesitamos criterios compartidos, una adecuada priorización de riesgos y una visión clara sobre dónde debe intervenir el juicio humano. La IA puede multiplicar nuestra capacidad, pero no puede sustituir la decisión sobre qué merece la pena validar, qué riesgo estamos dispuestos a asumir o qué significa realmente que una solución sea buena.
El World Quality Report 2025-26 de Capgemini apunta precisamente en esta dirección. La IA generativa está ganando protagonismo en la ingeniería de calidad, con aplicaciones que van desde el refinamiento de requisitos hasta el diseño de pruebas. Pero el informe también pone de manifiesto una dificultad que muchas organizaciones todavía no han resuelto, convertir estos usos de la IA en una mejora estable y sostenible de sus procesos de calidad.
Por eso, el siguiente paso de QA no debería ser simplemente hacer más pruebas ni hacerlas más deprisa. Debería ser desarrollar una capacidad continua para asegurar la calidad desde el momento en que nace una iniciativa hasta que la solución genera valor en el mundo real.
Ese es el enfoque de QA Coach: acompañar a las organizaciones en la construcción de un modelo propio de calidad que combine estrategia, gobierno y cultura, adaptándose a su nivel de madurez y a sus circunstancias concretas.
Porque la calidad no se implanta con una herramienta, un procedimiento o un departamento. Se construye en la forma en que una organización toma decisiones.
Cuando negocio define sus necesidades, cuando tecnología las convierte en soluciones, cuando los usuarios comprueban que esas soluciones funcionan en su realidad y cuando los responsables del proyecto mantienen alineadas todas esas perspectivas, la calidad deja de ser un control al final del proceso para convertirse en una responsabilidad compartida.
En un contexto en el que las organizaciones necesitan entregar soluciones cada vez más rápido, la calidad ya no puede limitarse a comprobar al final si algo funciona. Se debe ayudar desde el principio a definir qué significa hacerlo bien, qué riesgos asumir y sobre todo si estamos construyendo aquello que realmente necesitan el negocio y los usuarios
Ese es, probablemente, el cambio de mentalidad que necesitamos.
La calidad no pertenece exclusivamente a QA. Tampoco empieza cuando comienza el testing, y mucho menos debería aparecer cuando ya no queda tiempo para cambiar nada.
Si queremos aprovechar de verdad la velocidad que nos ofrecen la automatización y la inteligencia artificial, necesitamos compensarla con algo que ninguna tecnología puede decidir por nosotros, criterio.
Porque cuanto más rápido construimos, más importante es saber qué estamos construyendo.
Y cuanto antes empecemos a hablar de calidad, más posibilidades tendremos de que aquello que finalmente llegue a producción no solo funcione sino que funcione para lo que realmente importa.
