{"id":26237,"date":"2026-09-09T16:33:17","date_gmt":"2026-09-09T15:33:17","guid":{"rendered":"https:\/\/telecomkh.info\/?p=26237"},"modified":"2026-09-09T16:33:38","modified_gmt":"2026-09-09T15:33:38","slug":"un-software-que-funciona-tambien-puede-ser-un-fracaso","status":"publish","type":"post","link":"https:\/\/telecomkh.info\/?p=26237","title":{"rendered":"Un software que funciona tambi\u00e9n puede ser un fracaso"},"content":{"rendered":"

Aunque lleguemos a desarrollar a m\u00e1s velocidad no nos servir\u00e1 de nada si nos damos cuenta tarde de que la soluci\u00f3n construida es la equivocada<\/strong><\/p>\n

 <\/p>\n

Por Lilybeth Rodr\u00edguez, Gerente del \u00c1rea de Calidad de LedaMC<\/em><\/span><\/p>\n

Durante a\u00f1os, la transformaci\u00f3n digital ha llevado a las organizaciones a perseguir un objetivo aparentemente sencillo: hacer m\u00e1s, hacerlo mejor y, sobre todo, hacerlo m\u00e1s r\u00e1pido. Automatizaci\u00f3n, eficiencia operativa, nuevos productos digitales, innovaci\u00f3n constante\u2026 Y ahora, con especial intensidad, inteligencia artificial. La presi\u00f3n por acelerar las entregas no deja de crecer, mientras las empresas destinan cada vez m\u00e1s recursos a construir soluciones capaces de responder a un mercado que cambia a una velocidad dif\u00edcil de seguir.
\nPero hay una cuesti\u00f3n que en medio de toda esta carrera contin\u00faa sin resolverse del todo \u00bfQui\u00e9n se asegura de que aquello que estamos construyendo es realmente lo que necesitamos?
\nPorque que una soluci\u00f3n funcione t\u00e9cnicamente no significa necesariamente que haya sido un \u00e9xito. Tiene que responder a las necesidades del negocio, ser \u00fatil para quienes van a utilizarla, integrarse en los procesos de la organizaci\u00f3n y, en \u00faltima instancia, generar el valor que justific\u00f3 su desarrollo.
\nEsta diferencia es m\u00e1s habitual de lo que parece. Un producto puede superar las pruebas t\u00e9cnicas previstas y llegar a producci\u00f3n sin errores evidentes y, aun as\u00ed, no solucionar adecuadamente el problema para el que fue creado. En esos casos, el fallo no est\u00e1 necesariamente en la tecnolog\u00eda ni en la capacidad del equipo. Muchas veces est\u00e1 en algo mucho m\u00e1s b\u00e1sico y es que la calidad empez\u00f3 a formar parte de la conversaci\u00f3n demasiado tarde.
\nQuienes trabajamos en QA conocemos bien ese escenario. Proyectos que comienzan con buenos equipos, presupuesto y una planificaci\u00f3n aparentemente s\u00f3lida terminan acerc\u00e1ndose a producci\u00f3n con criterios de aceptaci\u00f3n 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.
\nY aqu\u00ed est\u00e1 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.
\nCuando QA participa desde las primeras etapas, las preguntas cambian. Ya no se trata \u00fanicamente de identificar qu\u00e9 est\u00e1 fallando, sino de establecer qu\u00e9 significa tener \u00e9xito. \u00bfQu\u00e9 necesita realmente el usuario? \u00bfQu\u00e9 condiciones deben cumplirse para considerar que una soluci\u00f3n responde a las expectativas del negocio? \u00bfCu\u00e1les son los riesgos que deber\u00edamos validar antes de continuar avanzando?
\nLa diferencia no es menor. No consiste en probar mejor, sino en definir antes qu\u00e9 significa hacerlo bien.
\nDurante mucho tiempo QA ha estado asociado principalmente a la ejecuci\u00f3n de pruebas antes de una puesta en producci\u00f3n. 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.
\nHist\u00f3ricamente, QA ha actuado como una especie de bisagra entre lo que la organizaci\u00f3n necesita y lo que tecnolog\u00eda construye. Hoy esa funci\u00f3n requiere una mirada mucho m\u00e1s amplia. Significa, por ejemplo, establecer criterios de aceptaci\u00f3n que negocio y TI interpreten de la misma manera, mantener la trazabilidad entre las necesidades iniciales y la soluci\u00f3n desarrollada y anticipar los riesgos en lugar de limitarse a descubrirlos cuando ya se han materializado.
\nTambi\u00e9n implica replantear c\u00f3mo abordamos las pruebas de aceptaci\u00f3n de usuario, las conocidas UAT. No deber\u00edan convertirse en una \u00faltima barrera antes de producci\u00f3n, ejecutada deprisa por usuarios que tienen que compaginar la validaci\u00f3n con sus responsabilidades habituales. Una UAT eficaz necesita preparaci\u00f3n, criterios claros, participaci\u00f3n adecuada y tiempo suficiente para que los usuarios puedan validar la soluci\u00f3n desde la perspectiva del negocio y de su realidad diaria.
\nY, naturalmente, habr\u00e1 hallazgos. Siempre los habr\u00e1. La cuesti\u00f3n es disponer de mecanismos claros para gestionarlos, priorizarlos, corregirlos y, algo todav\u00eda m\u00e1s importante, convertirlos en conocimiento que ayude a evitar que los mismos problemas vuelvan a repetirse.
\nTodo esto nos lleva a una conclusi\u00f3n, QA es mucho m\u00e1s que testing. Es una forma de conseguir que negocio, tecnolog\u00eda y usuarios compartan una misma definici\u00f3n de \u00e9xito a lo largo de todo el proyecto. En otras palabras, hablamos de gobernar la calidad.
\nEsta necesidad se vuelve todav\u00eda m\u00e1s evidente en un contexto en el que la velocidad de desarrollo se ha multiplicado. La inteligencia artificial est\u00e1 acelerando determinadas fases del ciclo de vida y puede ayudarnos a generar c\u00f3digo, analizar informaci\u00f3n, dise\u00f1ar escenarios de prueba o refinar requisitos. Pero existe una paradoja que no deber\u00edamos ignorar y es que cuanto m\u00e1s r\u00e1pido podemos construir, m\u00e1s r\u00e1pido podemos avanzar tambi\u00e9n en una direcci\u00f3n equivocada.
\nPor eso, acelerar no puede significar simplemente producir m\u00e1s. A mayor velocidad de entrega necesitamos tambi\u00e9n mayor capacidad para establecer criterios claros, identificar y priorizar riesgos y determinar en qu\u00e9 momentos la intervenci\u00f3n humana contin\u00faa siendo imprescindible.
\nEl World Quality Report 2025-26 de Capgemini refleja precisamente esta evoluci\u00f3n. La IA generativa est\u00e1 ganando presencia en la ingenier\u00eda de calidad y abre oportunidades relevantes en \u00e1mbitos como el refinamiento de requisitos y el dise\u00f1o de pruebas. Sin embargo, el informe tambi\u00e9n se\u00f1ala que muchas organizaciones todav\u00eda encuentran dificultades para transformar estos usos de la IA en mejoras sostenibles y consolidadas dentro de sus procesos de calidad.
\nLa cuesti\u00f3n, por tanto, no es si podemos utilizar IA para revisar m\u00e1s informaci\u00f3n, generar m\u00e1s escenarios o automatizar m\u00e1s tareas. Podemos hacerlo. La cuesti\u00f3n previa es mucho m\u00e1s importante: saber qu\u00e9 queremos validar, por qu\u00e9 necesitamos validarlo y qu\u00e9 impacto tiene aquello que estamos construyendo.
\nDe ah\u00ed que la evoluci\u00f3n natural de QA no deba consistir en hacer cada vez m\u00e1s testing, ni \u00fanicamente en hacerlo m\u00e1s r\u00e1pido. El verdadero salto est\u00e1 en desarrollar una capacidad permanente para asegurar la calidad desde el inicio y durante todo el ciclo de vida de una soluci\u00f3n.
\nEse 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\u00f3rmula universal, sino de acompa\u00f1ar a los equipos para que desarrollen una manera de trabajar en la que la calidad forme parte de las decisiones y no aparezca \u00fanicamente como una comprobaci\u00f3n final.
\nEsto significa crear una cultura en la que negocio, tecnolog\u00eda y usuarios compartan criterios, en la que la IA se utilice all\u00ed donde realmente aporta valor y en la que cada entrega genere conocimiento \u00fatil para mejorar la siguiente. Porque la calidad no deber\u00eda depender de una persona concreta, de un departamento o de una fase determinada del proyecto.
\nLa calidad pertenece a todos. Al negocio, cuando define qu\u00e9 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\u00f3n com\u00fan.
\nPor eso, asegurar la calidad en el desarrollo de software no puede seguir siendo una conversaci\u00f3n que se mantiene en segundo plano hasta las \u00faltimas semanas de un proyecto, ni una responsabilidad que se deposita exclusivamente en el equipo de QA.
\nLa calidad empieza mucho antes de ejecutar una prueba. Empieza cuando decidimos qu\u00e9 problema queremos resolver, c\u00f3mo sabremos que lo hemos resuelto y qu\u00e9 riesgos estamos dispuestos, o no, a asumir.
\nEn un entorno donde cada vez podemos construir m\u00e1s r\u00e1pido, la ventaja no estar\u00e1 \u00fanicamente en nuestra capacidad para entregar. Estar\u00e1 en nuestra capacidad para saber qu\u00e9 merece la pena entregar y asegurarnos de que lo hacemos bien desde el principio.<\/p>\n

Arriba, en la foto, Lilybeth Rodr\u00edguez, Gerente del \u00c1rea de Calidad de LedaMC<\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Aunque lleguemos a desarrollar a m\u00e1s velocidad no nos servir\u00e1 de nada si nos damos cuenta tarde de que la soluci\u00f3n construida es la equivocada   Por Lilybeth Rodr\u00edguez, Gerente del \u00c1rea de Calidad de LedaMC Durante a\u00f1os, la transformaci\u00f3n digital ha llevado a las organizaciones a perseguir un objetivo aparentemente sencillo: hacer m\u00e1s, hacerlo … <\/p>\n

Continue reading \u00abUn software que funciona tambi\u00e9n puede ser un fracaso\u00bb<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":26238,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,67],"tags":[],"_links":{"self":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/26237"}],"collection":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=26237"}],"version-history":[{"count":2,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/26237\/revisions"}],"predecessor-version":[{"id":26240,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/26237\/revisions\/26240"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/media\/26238"}],"wp:attachment":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=26237"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=26237"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=26237"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}