La responsable de Calidad y de la Oficina Técnica y Proyectos de LKS Next analiza cómo la inteligencia artificial está transformando el desarrollo de software y por qué la calidad, la seguridad y el gobierno son ahora más importantes que nunca.
Beatriz Pérez Lamancha lleva más de 25 años trabajando alrededor de una misma pregunta: cómo construir software fiable, verificable y mantenible.
Su trayectoria comenzó en Uruguay, entre el desarrollo, la docencia y la investigación, y continuó en España con un doctorado cum laude por la Universidad de Castilla-La Mancha. Su tesis dio lugar a MATE, una metodología para la automatización de pruebas dirigidas por modelos. Participó también en la creación del Centro de Ensayos de Software de Uruguay, una iniciativa pionera para profesionalizar el testing y acercar el conocimiento académico a las necesidades reales de las organizaciones.
Desde 2019 es responsable de Calidad en LKS Next y, desde septiembre de 2025, dirige también el equipo de Oficina Técnica y Proyectos. Desde esta posición trabaja en la convergencia entre ingeniería de calidad, DevSecOps, automatización, seguridad e inteligencia artificial aplicada al ciclo de vida del software.
En esta entrevista explica por qué la llegada de la IA no reduce la necesidad de controlar la calidad, sino que obliga a reforzarla.
Tu carrera está muy vinculada a la calidad del software. ¿Cómo empezó todo?
Empecé en el mundo del desarrollo y del análisis de sistemas. Entré como profesor ayudante en el Departamento de Ingeniería de Software de la Universidad de la República, al mismo tiempo que trabajaba en la industria como analista funcional. Esa combinación entre la universidad y la práctica profesional me permitió conocer de cerca tanto la investigación y la docencia como las necesidades reales de los proyectos.
Tras la crisis de 2002 en Uruguay, la industria del software uruguaya comenzó a orientarse cada vez más hacia la exportación. Las empresas comprendieron entonces que los problemas de calidad podían tener un impacto muy elevado: no es lo mismo realizar el mantenimiento en el lugar donde trabajan los técnicos que asumir el coste de desplazarlos a otro país para resolver problemas en producción que podrían haberse detectado y solucionado previamente mediante pruebas. Los problemas no se encontraban en la instalación, sino mucho antes: en una especificación ambigua, en un requisito mal entendido o en una decisión que nadie había validado.
En ese contexto, la Cámara Uruguaya de Tecnologías de la Información (CUTI) y la Facultad de Ingeniería de la Universidad de la República impulsaron la creación del Centro de Ensayos de Software. Yo era docente en la Facultad y estaba a punto de comenzar mi máster, así que empecé a trabajar en esta iniciativa. Allí desarrollamos actividades de testing, consultoría, formación e investigación aplicada.
Todo confluyó para orientar mi trayectoria hacia el testing. Mi tesis de máster se centró en el testing funcional independiente y, posteriormente, mi doctorado abordó la automatización de pruebas dirigidas por modelos. La pregunta de fondo siempre ha sido la misma: cómo incorporar la calidad desde el principio y descubrir los problemas lo antes posible.
También participaste en la creación del Centro de Ensayos de Software de Uruguay. ¿Qué supuso aquella experiencia?
Supuso una experiencia muy importante y una oportunidad para conectar tres mundos que no siempre dialogan lo suficiente: la universidad, la investigación y las necesidades concretas de las empresas.
Yo participé desde 2004 en la definición y puesta en marcha del Centro de Ensayos de Software (CES), donde desarrollamos actividades de testing, consultoría, formación e investigación aplicada. No se trataba únicamente de detectar errores, sino de ayudar a las organizaciones a establecer procesos, seleccionar herramientas, formar a sus equipos y entender la calidad como una capacidad estratégica.
Además, aquella experiencia coincidió con el comienzo de mi máster y terminó de orientar mi trayectoria hacia el testing. Me confirmó algo que sigo defendiendo hoy: una metodología solo aporta valor cuando puede trasladarse a un proyecto real, ser utilizada por los equipos y producir resultados observables y medibles. Cada empresa es distinta; por eso, no existe una solución válida para todas ni una metodología que pueda aplicarse de la misma manera en cualquier contexto.
¿Es ahí donde la calidad se encuentra con el DevSecOps?
Exactamente. DevSecOps supone integrar desarrollo, operaciones, seguridad y calidad en un mismo flujo de trabajo.
No consiste simplemente en incorporar una herramienta al pipeline. Implica definir qué controles deben realizarse, en qué momento, con qué criterios y qué ocurre cuando no se cumplen. Incluye la revisión del código, las pruebas automatizadas —unitarias, de integración y funcionales—, el análisis de vulnerabilidades, el control de dependencias, la trazabilidad y la supervisión de los despliegues.
El objetivo es recibir información lo antes posible. Cuanto antes detectemos una desviación, más fácil será corregirla. Para conseguirlo necesitamos automatización, pero también una estrategia clara y equipos que compartan la responsabilidad sobre el resultado.
Una herramienta puede identificar un problema, pero la organización debe decidir qué considera aceptable, qué bloquea una entrega y quién asume cada decisión.
¿Cómo está cambiando la inteligencia artificial el desarrollo de software?
La IA está cambiando cada día la forma de desarrollar software y está acelerando todas sus actividades. Puede ayudar a analizar requisitos, generar código, proponer pruebas, documentar sistemas, detectar patrones o asistir en la resolución de incidencias. Nos permite reducir el trabajo repetitivo y dedicar más tiempo a tareas de mayor valor.
El problema de esa aceleración aparece en la mantenibilidad, la seguridad y la fiabilidad de los resultados. Podemos introducir más errores, más deuda técnica o más código difícil de entender o inseguro que demos por válido y que, posteriormente, resulte más complicado de mantener.
El gran reto no consiste únicamente en aprender a utilizar asistentes de IA, sino en integrarlos en un proceso de ingeniería de software que permita comprobar sus resultados. Debemos saber qué herramientas utilizamos, en qué casos, con qué datos y bajo qué condiciones de seguridad, así como medir si realmente están mejorando el trabajo.
La revisión humana sigue siendo fundamental. La IA puede proponer, generar o analizar, pero la responsabilidad sobre el software y sus consecuencias continúa siendo nuestra.
¿Qué aplicaciones de la IA consideras más prometedoras en el ámbito del testing?
La IA tiene un potencial enorme en el testing. Puede ayudarnos a generar casos de prueba a partir de requisitos, historias de usuario y criterios de aceptación, así como a identificar ambigüedades, inconsistencias o escenarios que no se han contemplado. También puede transformar esos casos en formatos estructurados, como BDD o Gherkin, y generar o mantener pruebas unitarias, de integración y funcionales.
Otra aplicación interesante es el análisis de la cobertura y de los resultados de las pruebas. La IA puede ayudarnos a detectar huecos en la cobertura, identificar escenarios de riesgo, priorizar las pruebas de regresión y analizar los motivos por los que una prueba ha fallado. También puede ser útil para proponer datos de prueba, generar diferentes combinaciones de entrada y detectar patrones en los defectos encontrados.
Hay que tener cuidado con la falsa seguridad que nos da la IA en el testing. Una mayor cobertura de código o un mayor número de pruebas no implica necesariamente una mejor calidad. Lo importante es comprobar si las pruebas cubren los riesgos relevantes, si verifican el comportamiento esperado, si detectan defectos reales y si pueden mantenerse cuando evoluciona el sistema. También hay que controlar problemas como las pruebas redundantes, frágiles o excesivamente acopladas a la implementación.
Por eso, la IA debe utilizarse como apoyo al conocimiento y al criterio de los profesionales del testing, no como sustituto. Cada prueba generada debe revisarse y validarse, y las herramientas deben evaluarse de forma continua con casos reales de la organización, midiendo aspectos como la corrección, la cobertura efectiva, la mantenibilidad, el esfuerzo de revisión y el valor que aportan al proceso de calidad.
Resulta fundamental mantener la observabilidad del cambio tecnologico, que nos permita conocer nuevas herramientas, modelos y formas de aplicar la IA al testing. Precisamente por eso trabajamos en I+D: para experimentar con estas tecnologías, evaluar sus resultados con rigor y determinar en qué contextos pueden aportar un valor real a la ingeniería de software y a la calidad.
Tu equipo también investiga cómo evaluar estas herramientas. ¿Qué están aprendiendo?
Una de las principales conclusiones es que no podemos adoptar una herramienta de IA basándonos únicamente en una demostración o en una percepción inicial de productividad.
En CIbSE 2025 recibimos el premio al mejor artículo por un trabajo relacionado con la generación de pruebas unitarias mediante grandes modelos de lenguaje. También presentamos en EASE 2025 una propuesta para evaluar de manera continua las herramientas de IA aplicadas al testing. Esta línea tuvo continuidad en 2026 con un artículo publicado en Science of Computer Programming sobre la adopción sistemática y basada en evidencias de herramientas apoyadas en modelos de lenguaje.
Debemos experimentar, comparar y medir. Y esa medición no debe limitarse a comprobar cuánto contenido genera. Debe analizar también la corrección, la cobertura, la mantenibilidad, el esfuerzo de revisión, los riesgos y el valor real que aporta al equipo.
¿Qué significa gobernar la IA dentro del ciclo de vida del software?
Significa pasar de utilizar herramientas de manera individual y dispersa a establecer un marco compartido para toda la organización.
Ese marco debe definir los casos de uso permitidos, las herramientas autorizadas, el tratamiento de la información, las responsabilidades, los controles de seguridad y los mecanismos de validación. También debe establecer cómo se mide el impacto y cómo se gestionan los riesgos.
No se trata de crear una capa burocrática que frene a los equipos. Un buen gobierno debe facilitar la adopción, proporcionar seguridad y evitar que cada persona tenga que resolver por su cuenta las mismas dudas.
También es importante diferenciar entre experimentar y llevar una solución a producción. La experimentación necesita espacio, pero cuando una herramienta empieza a intervenir en procesos críticos debemos exigir trazabilidad, supervisión y evidencias de que funciona como esperamos.
¿Cómo ha evolucionado LKS Next en este ámbito desde tu incorporación en 2019?
Cuando me incorporé, el objetivo era reforzar la calidad de manera transversal, acompañar a los equipos y consolidar criterios, procesos y herramientas comunes.
Desde entonces hemos evolucionado hacia una visión más amplia, calidad durante todo el ciclo de vida: desde los requisitos y la arquitectura hasta el despliegue, la operación y la mejora continua.
La Oficina Técnica nos permite conectar esa visión con los proyectos reales. Trabajamos en estándares, herramientas, métricas, automatización, modernización de aplicaciones y acompañamiento a los equipos, pero también en cómo integrar la IA, seguridad y la inteligencia artificial de una manera coherente en nuestros clientes.
La evolución natural nos ha llevado desde la calidad hacia DevSecOps y, ahora, hacia la aplicación gobernada de la IA en el desarrollo. No son etapas desconectadas. Es el mismo objetivo adaptado a un entorno que cambia: producir software seguro, confiable y mantenible.
¿Por dónde debería empezar una empresa que quiera introducir IA en sus procesos de desarrollo?
Empezaría por la gobernanza, identificando claramente qué usos necesitamos de la IA y definiendo, a partir de ahí, qué herramientas pueden ayudarnos. No empezaría por la herramienta, sino por los problemas concretos que queremos resolver: dónde se está perdiendo tiempo, dónde aparecen errores recurrentes o qué actividades podrían mejorar con la asistencia de la IA.
En segundo lugar, hay que formar a los profesionales. No solo en el uso de las herramientas, sino también en sus limitaciones, en los riesgos asociados y en la necesidad de revisar y validar sus resultados. La adopción de la IA exige criterio técnico y una responsabilidad compartida sobre la calidad, la seguridad y la mantenibilidad del software.
En paralelo, sentaría las bases de la automatización, si todavía no están definidas. Es fundamental contar con un proceso sólido de DevSecOps que permita comprobar la calidad y la seguridad del software de forma automatizada con cada cambio, incorporando las pruebas, el análisis del código, la revisión de vulnerabilidades y el control de dependencias al flujo habitual de desarrollo.
Por último, empezaría con un piloto acotado, vinculado a un problema concreto y con un equipo pequeño. Antes de comenzar, establecería una situación de partida y definiría qué queremos mejorar. Después mediría los resultados con métricas técnicas y de negocio.
A partir de esas evidencias, decidiríamos si tiene sentido ampliar el uso de la solución. La adopción de la IA debe incluir un seguimiento continuo, la revisión de las métricas y un proceso de mejora que permita ajustar los usos, los costes, las herramientas, la formación y el propio modelo de gobernanza.
¿Qué papel tendrán los profesionales de calidad en esta nueva etapa?
Hace un tiempo, un miembro de nuestro equipo asistió a una charla de un «influencer» del ámbito de la inteligencia artificial en la que se afirmó que el rol del tester había muerto. Era la época del boom del vibe coding. Hoy, aquella afirmación se ha convertido en una broma interna.
La realidad es que la forma de trabajar con IA ha seguido evolucionando rápidamente: hemos pasado del vibe coding a trabajar con agentes, skills y otros sistemas capaces de generar y ejecutar tareas de manera autónoma. En este contexto, es cada vez más importante contar con profesionales de calidad que sepan qué deben hacer esos agentes, qué riesgos pueden introducir y cómo validar sus resultados.
La IA puede automatizar parte del trabajo, pero necesitamos personas capaces de formular las preguntas correctas, identificar riesgos, diseñar estrategias de prueba y determinar si una respuesta o un resultado son realmente válidos. El papel del tester no desaparece; evoluciona hacia una función más estratégica, con mayor capacidad para definir los criterios de calidad y supervisar sistemas cada vez más complejos.
También cobra especial importancia la trazabilidad. Debemos poder relacionar los requisitos con las decisiones de diseño, el código que se genera, las pruebas que lo validan y las evidencias obtenidas. Cuando intervienen agentes de IA, esa cadena debe estar especialmente clara para saber qué se pidió, qué se modificó, qué se comprobó y con qué resultados. Sin trazabilidad, resulta difícil evaluar la cobertura, analizar un fallo o asumir la responsabilidad sobre el software.
Los perfiles de calidad tendrán que comprender mejor el desarrollo, la seguridad, los datos y el funcionamiento de los modelos. Al mismo tiempo, los equipos de desarrollo deberán asumir que la calidad no es responsabilidad exclusiva de un área especializada.
Perfil
Beatriz Pérez Lamancha es responsable de Calidad y de la Oficina Técnica y Proyectos de LKS Next. Es doctora cum laude por la Universidad de Castilla-La Mancha, máster en Informática y en Tecnologías Avanzadas en Informática, e ingeniera en Computación por la Universidad de la República de Uruguay.
Cuenta con las certificaciones TMap Next, ISTQB Foundation e ISTQB Advanced Test Manager. A lo largo de su trayectoria ha trabajado en desarrollo, investigación, docencia, consultoría, dirección de calidad y creación de oficinas técnicas. Su especialización abarca ingeniería de software, testing, automatización, DevSecOps y adopción gobernada de inteligencia artificial.
